What's the difference between HEAD^ and HEAD~ in Git?
When I specify an ancestor commit object in Git, I'm confused between HEAD^ and HEAD~.
Both have a "numbered" version like HEAD^3 and HEAD~2.
They seem very similar or the same to me, but are there any differences between the tilde and the caret?
git
add a comment |
When I specify an ancestor commit object in Git, I'm confused between HEAD^ and HEAD~.
Both have a "numbered" version like HEAD^3 and HEAD~2.
They seem very similar or the same to me, but are there any differences between the tilde and the caret?
git
37
it is bad to paste links, i know but this is the best explanation I found and there is picture in it. paulboxley.com/blog/2011/06/git-caret-and-tilde
– igor
Nov 13 '13 at 16:38
3
Links are especially bad when they are broken. That is the reason why it is safer to answer the question which help prevent this because of the ability to copy paste some explanations :)
– Samuel
Aug 16 '17 at 11:39
add a comment |
When I specify an ancestor commit object in Git, I'm confused between HEAD^ and HEAD~.
Both have a "numbered" version like HEAD^3 and HEAD~2.
They seem very similar or the same to me, but are there any differences between the tilde and the caret?
git
When I specify an ancestor commit object in Git, I'm confused between HEAD^ and HEAD~.
Both have a "numbered" version like HEAD^3 and HEAD~2.
They seem very similar or the same to me, but are there any differences between the tilde and the caret?
git
git
edited Aug 31 '15 at 20:20
mkobit
20.5k684100
20.5k684100
asked Feb 8 '10 at 12:56
TK.TK.
10.2k195671
10.2k195671
37
it is bad to paste links, i know but this is the best explanation I found and there is picture in it. paulboxley.com/blog/2011/06/git-caret-and-tilde
– igor
Nov 13 '13 at 16:38
3
Links are especially bad when they are broken. That is the reason why it is safer to answer the question which help prevent this because of the ability to copy paste some explanations :)
– Samuel
Aug 16 '17 at 11:39
add a comment |
37
it is bad to paste links, i know but this is the best explanation I found and there is picture in it. paulboxley.com/blog/2011/06/git-caret-and-tilde
– igor
Nov 13 '13 at 16:38
3
Links are especially bad when they are broken. That is the reason why it is safer to answer the question which help prevent this because of the ability to copy paste some explanations :)
– Samuel
Aug 16 '17 at 11:39
37
37
it is bad to paste links, i know but this is the best explanation I found and there is picture in it. paulboxley.com/blog/2011/06/git-caret-and-tilde
– igor
Nov 13 '13 at 16:38
it is bad to paste links, i know but this is the best explanation I found and there is picture in it. paulboxley.com/blog/2011/06/git-caret-and-tilde
– igor
Nov 13 '13 at 16:38
3
3
Links are especially bad when they are broken. That is the reason why it is safer to answer the question which help prevent this because of the ability to copy paste some explanations :)
– Samuel
Aug 16 '17 at 11:39
Links are especially bad when they are broken. That is the reason why it is safer to answer the question which help prevent this because of the ability to copy paste some explanations :)
– Samuel
Aug 16 '17 at 11:39
add a comment |
13 Answers
13
active
oldest
votes
HEAD^ means the first parent of the tip of the current branch.
Remember that git commits can have more than one parent. HEAD^ is short for HEAD^1, and you can also address HEAD^2 and so on as appropriate.
You can get to parents of any commit, not just HEAD. You can also move back through generations: for example, master~2 means the grandparent of the tip of the master branch, favoring the first parent in cases of ambiguity. These specifiers can be chained arbitrarily
, e.g., topic~3^2.
For the full details, see "Specifying Revisions" in the git rev-parse documentation.
To have a visual representation of the idea let's quote part of documentation:
Here is an illustration, by Jon Loeliger. Both commit nodes B and C are parents of commit node A. Parent commits are ordered left-to-right.
G H I J
/ /
D E F
| /
| / |
|/ |
B C
/
/
A
A = = A^0
B = A^ = A^1 = A~1
C = A^2
D = A^^ = A^1^1 = A~2
E = B^2 = A^^2
F = B^3 = A^^3
G = A^^^ = A^1^1^1 = A~3
H = D^2 = B^^2 = A^^^2 = A~2^2
I = F^ = B^3^ = A^^3^
J = F^2 = B^3^2 = A^^3^2
54
One thing that is often unmentioned is how to know which is the first or second parent. You can usegit logorgit show. If it's a merge commit with multiple parents, the parents will be listed in order of first, second, etc.
– wisbucky
Mar 19 '15 at 20:17
4
Why is this so hard for me to remember which one does what?! Does anybody have a memory cue or dumb saying for these? Possibly something like PECS? I tried myself but my brain keeps trying to make a relationship between caret and Carrot Top, and that is not working :(.
– mkobit
Nov 17 '15 at 18:08
34
way to remember: '~' is "fuzzy" or "approximate" (i.e., you only get the first parent) while '^' is precise (so goes through every single commit).
– bwv549
Feb 24 '16 at 21:25
4
I reply to myself: git merge branch1 branch2 branch3...
– superruzafa
Feb 20 '17 at 11:28
8
@duckx the graph is actually going top-to-bottom, so A is the most recent commit, and G is one of the oldest. The path from G to D is forward, not backward, from what I can tell.
– goldenratio
Mar 17 '17 at 18:12
|
show 8 more comments
The difference between HEAD^ and HEAD~ is well described by the illustration (by Jon Loeliger) found on http://www.kernel.org/pub/software/scm/git/docs/git-rev-parse.html.
This documentation can be a bit obscure to beginners so I've reproduced that illustration below:
G H I J
/ /
D E F
| /
| / |
|/ |
B C
/
/
A
A = = A^0
B = A^ = A^1 = A~1
C = A^2
D = A^^ = A^1^1 = A~2
E = B^2 = A^^2
F = B^3 = A^^3
G = A^^^ = A^1^1^1 = A~3
H = D^2 = B^^2 = A^^^2 = A~2^2
I = F^ = B^3^ = A^^3^
J = F^2 = B^3^2 = A^^3^2
18
Seeing is understanding! Thanks for the explicit diagram.
– kontur
Jan 14 '14 at 8:55
8
Just one question. How is it possible for a commit to have more than two parents? (See B - it's parents are D, E and F) I imagine that the only way a commit can have two parents is when it is a merge commit... but how can you merge 3 commits at the same time?
– tsikov
Sep 29 '15 at 14:01
If I'm not mistaken, this may be obvious, but I think it should be specified that HEAD~ follows the current branch (like Diego Dias mentioned below).
– fibono
Oct 30 '15 at 13:40
2
Additionally,F = A^2^.
– Mateen Ulhaq
Feb 11 '16 at 20:12
1
So,^ == ^1 == LEFTMOST PARENT,^2 == SECOND LEFTMOST PARENTand so forth. And~ == ~1 == LEFTMOST PARENT,~2 == LEFTMOST PARENTS LEFTMOST PARENT == LEFTMOST GRANDPARENT. By extension,~2^2 == LEFTMOST GRANDPARENTS SECOND LEFTMOST PARENT
– Alexander Torstling
Jun 4 '18 at 19:00
|
show 1 more comment
Both ~ and ^ on their own refer to the parent of the commit (~~ and ^^ both refer to the grandparent commit, etc.) But they differ in meaning when they are used with numbers:
~2means up two levels in the hierarchy, via the first parent if a commit has more than one parent^2means the second parent where a commit has more than one parent (i.e. because it's a merge)
These can be combined, so HEAD~2^3 means HEAD's grandparent commit's third parent commit.
1
Reading this followed by the picture from stackoverflow.com/questions/2221658/… made perfect sense.
– kunigami
Sep 7 '15 at 16:57
13
This should be the accepted answer, much more succinct and useful than the others.
– RichVel
Mar 27 '16 at 8:47
1
This answer made me distinguish between caret/tilde without number and with number! I thought^^was the same as^2but it's not .
– Alexander Derck
Oct 16 '18 at 10:44
add a comment |
My two cents...

And howH=A~2^2notH=A~2^1?
– Mohammad Faisal
Dec 10 '18 at 14:11
If I had figured it out correctly, the commitsA,B,D,Gare on the same branch and the commitDis a merge ofGandH, therefore having two parents. So the commit (H) from other branch is reference by^2.
– Mohammad Faisal
Dec 10 '18 at 14:27
add a comment |
Here's a very good explanation taken verbatim from http://www.paulboxley.com/blog/2011/06/git-caret-and-tilde :
ref~is shorthand forref~1and means the commit's first parent.ref~2means the commit's first parent's first parent.ref~3means the commit's first parent's first parent's first parent. And so on.
ref^is shorthand forref^1and means the commit's first parent. But where the two differ is thatref^2means the commit's second parent (remember, commits can have two parents when they are a merge).
The
^and~operators can be combined.

add a comment |
The ^<n> format allows you to select the nth parent of the commit (relevant in merges). The ~<n> format allows you to select the nth ancestor commit, always following the first parent. See git-rev-parse's documentation for some examples.
add a comment |
It is worth noting that git also has a syntax for tracking "from-where-you-came"/"want-to-go-back-now" - for example, HEAD@{1} will reference the place from where you jumped to new commit location.
Basically HEAD@{} variables capture the history of HEAD movement, and you can decide to use a particular head by looking into reflogs of git using the command git reflog.
Example:
0aee51f HEAD@{0}: reset: moving to HEAD@{5}
290e035 HEAD@{1}: reset: moving to HEAD@{7}
0aee51f HEAD@{2}: reset: moving to HEAD@{3}
290e035 HEAD@{3}: reset: moving to HEAD@{3}
9e77426 HEAD@{4}: reset: moving to HEAD@{3}
290e035 HEAD@{5}: reset: moving to HEAD@{3}
0aee51f HEAD@{6}: reset: moving to HEAD@{3}
290e035 HEAD@{7}: reset: moving to HEAD@{3}
9e77426 HEAD@{8}: reset: moving to HEAD@{3}
290e035 HEAD@{9}: reset: moving to HEAD@{1}
0aee51f HEAD@{10}: reset: moving to HEAD@{4}
290e035 HEAD@{11}: reset: moving to HEAD^
9e77426 HEAD@{12}: reset: moving to HEAD^
eb48179 HEAD@{13}: reset: moving to HEAD~
f916d93 HEAD@{14}: reset: moving to HEAD~
0aee51f HEAD@{15}: reset: moving to HEAD@{5}
f19fd9b HEAD@{16}: reset: moving to HEAD~1
290e035 HEAD@{17}: reset: moving to HEAD~2
eb48179 HEAD@{18}: reset: moving to HEAD~2
0aee51f HEAD@{19}: reset: moving to HEAD@{5}
eb48179 HEAD@{20}: reset: moving to HEAD~2
0aee51f HEAD@{21}: reset: moving to HEAD@{1}
f916d93 HEAD@{22}: reset: moving to HEAD@{1}
0aee51f HEAD@{23}: reset: moving to HEAD@{1}
f916d93 HEAD@{24}: reset: moving to HEAD^
0aee51f HEAD@{25}: commit (amend): 3rd commmit
35a7332 HEAD@{26}: checkout: moving from temp2_new_br to temp2_new_br
35a7332 HEAD@{27}: commit (amend): 3rd commmit
72c0be8 HEAD@{28}: commit (amend): 3rd commmit
An example could be that I did local-commits a->b->c->d and then I went back discarding 2 commits to check my code - git reset HEAD~2 - and then after that I want to move my HEAD back to d - git reset HEAD@{1}.
add a comment |
HEAD^^^ is the same as HEAD~3, selecting the third commit before HEAD
HEAD^2 specifies the second head in a merge commit
add a comment |
HEAD~ specifies the first parent on a "branch"
HEAD^ allows you to select a specific parent of the commit
An Example:
If you want to follow a side branch, you have to specify something like
master~209^2~15
add a comment |
TLDR
~ is what you want most of the time, it references past commits to the current branch
^ references parents (git-merge creates a 2nd parent or more)
A~ is always the same as A^
A~~ is always the same as A^^, and so on
A~2 is not the same as A^2 however,
because ~2 is shorthand for ~~
while ^2 is not shorthand for anything, it means the 2nd parent
add a comment |
Simplistically:
~specifies ancestors
^specifies parents
You can specify one or more branches when merging. Then a commit has two or more parents and then ^ is useful to indicate parents.
Suppose you are on branch A and you have two more branches: B and C.
On each branch the three last commits are:
A: A1, A2, A3
B: B1, B2, B3
C: C1, C3, C3
If now on branch A you execute the command:
git merge B C
then you are combining three branches together (here your merge commit has three parents)
and
~ indicates the n'th ancestor in the first branch, so
HEAD~indicates A3
HEAD~2indicates A2
HEAD~3indicates A1
^ indicates the n'th parent, so
HEAD^indicates A3
HEAD^2indicates B3
HEAD^3indicates C3
The next use of ~ or ^ next to each other is in the context of the commit designated by previous characters.
Notice 1:
HEAD~3is always equal to:HEAD~~~and to:HEAD^^^(every indicates A1),
and generally:
HEAD~nis always equal to:HEAD~...~(n times~) and to:HEAD^...^(n times^).
Notice 2:
HEAD^3is not the same asHEAD^^^(the first indicates C3 and the second indicates A1),
and generally:
HEAD^1is the same asHEAD^,- but for n > 1:
HEAD^nis always not the same asHEAD^...^(n times~).
add a comment |
actual example of the difference between HEAD~ and HEAD^

add a comment |
Simply put, for the first level of parentage (ancestry, inheritance, lineage, etc.) HEAD^ and HEAD~ both point to the same commit, which is (located) one parent above the HEAD (commit).
Furthermore, HEAD^ = HEAD^1 = HEAD~ = HEAD~1. But HEAD^^ != HEAD^2 != HEAD~2. Yet HEAD^^ = HEAD~2. Read on.
Beyond the first level of parentage, things get trickier, especially if the working branch/master branch has had merges (from other branches). There is also the matter of syntax with the caret, HEAD^^ = HEAD~2 (they're equivalent) BUT HEAD^^ != HEAD^2 (they're two different things entirely).
Each/the caret refers to the HEAD's first parent, which is why carets stringed together are equivalent to tilde expressions, because they refer to the first parent's (first parent's) first parents, etc., etc. based strictly on the number on connected carets or on the number following the tilde (either way, they both mean the same thing), i.e. stay with the first parent and go up x generations.
HEAD~2 (or HEAD^^) refers to the commit that is two levels of ancestry up/above the current commit (the HEAD) in the hierarchy, meaning the HEAD's grandparent commit.
HEAD^2, on the other hand, refers NOT to the first parent's second parent's commit, but simply to the second parent's commit. That is because the caret means the parent of the commit, and the number following signifies which/what parent commit is referred to (the first parent, in the case when the caret is not followed by a number [because it is shorthand for the number being 1, meaning the first parent]). Unlike the caret, the number that follows afterwards does not imply another level of hierarchy upwards, but rather it implies how many levels sideways, into the hierarchy, one needs to go find the correct parent (commit). Unlike the number in a tilde expression, it is only one parent up in the hierarchy, regardless of the number (immediately) proceeding the caret. Instead of upward, the caret's trailing number counts sideways for parents across the hierarchy [at a level of parents upwards that is equivalent to the number of consecutive carets].
So HEAD^3 is equal to the third parent of the HEAD commit (NOT the great-grandparent, which is what HEAD^^^ AND HEAD~3 would be...).
add a comment |
Your Answer
StackExchange.ifUsing("editor", function () {
StackExchange.using("externalEditor", function () {
StackExchange.using("snippets", function () {
StackExchange.snippets.init();
});
});
}, "code-snippets");
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "1"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});
function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});
}
});
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f2221658%2fwhats-the-difference-between-head-and-head-in-git%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
13 Answers
13
active
oldest
votes
13 Answers
13
active
oldest
votes
active
oldest
votes
active
oldest
votes
HEAD^ means the first parent of the tip of the current branch.
Remember that git commits can have more than one parent. HEAD^ is short for HEAD^1, and you can also address HEAD^2 and so on as appropriate.
You can get to parents of any commit, not just HEAD. You can also move back through generations: for example, master~2 means the grandparent of the tip of the master branch, favoring the first parent in cases of ambiguity. These specifiers can be chained arbitrarily
, e.g., topic~3^2.
For the full details, see "Specifying Revisions" in the git rev-parse documentation.
To have a visual representation of the idea let's quote part of documentation:
Here is an illustration, by Jon Loeliger. Both commit nodes B and C are parents of commit node A. Parent commits are ordered left-to-right.
G H I J
/ /
D E F
| /
| / |
|/ |
B C
/
/
A
A = = A^0
B = A^ = A^1 = A~1
C = A^2
D = A^^ = A^1^1 = A~2
E = B^2 = A^^2
F = B^3 = A^^3
G = A^^^ = A^1^1^1 = A~3
H = D^2 = B^^2 = A^^^2 = A~2^2
I = F^ = B^3^ = A^^3^
J = F^2 = B^3^2 = A^^3^2
54
One thing that is often unmentioned is how to know which is the first or second parent. You can usegit logorgit show. If it's a merge commit with multiple parents, the parents will be listed in order of first, second, etc.
– wisbucky
Mar 19 '15 at 20:17
4
Why is this so hard for me to remember which one does what?! Does anybody have a memory cue or dumb saying for these? Possibly something like PECS? I tried myself but my brain keeps trying to make a relationship between caret and Carrot Top, and that is not working :(.
– mkobit
Nov 17 '15 at 18:08
34
way to remember: '~' is "fuzzy" or "approximate" (i.e., you only get the first parent) while '^' is precise (so goes through every single commit).
– bwv549
Feb 24 '16 at 21:25
4
I reply to myself: git merge branch1 branch2 branch3...
– superruzafa
Feb 20 '17 at 11:28
8
@duckx the graph is actually going top-to-bottom, so A is the most recent commit, and G is one of the oldest. The path from G to D is forward, not backward, from what I can tell.
– goldenratio
Mar 17 '17 at 18:12
|
show 8 more comments
HEAD^ means the first parent of the tip of the current branch.
Remember that git commits can have more than one parent. HEAD^ is short for HEAD^1, and you can also address HEAD^2 and so on as appropriate.
You can get to parents of any commit, not just HEAD. You can also move back through generations: for example, master~2 means the grandparent of the tip of the master branch, favoring the first parent in cases of ambiguity. These specifiers can be chained arbitrarily
, e.g., topic~3^2.
For the full details, see "Specifying Revisions" in the git rev-parse documentation.
To have a visual representation of the idea let's quote part of documentation:
Here is an illustration, by Jon Loeliger. Both commit nodes B and C are parents of commit node A. Parent commits are ordered left-to-right.
G H I J
/ /
D E F
| /
| / |
|/ |
B C
/
/
A
A = = A^0
B = A^ = A^1 = A~1
C = A^2
D = A^^ = A^1^1 = A~2
E = B^2 = A^^2
F = B^3 = A^^3
G = A^^^ = A^1^1^1 = A~3
H = D^2 = B^^2 = A^^^2 = A~2^2
I = F^ = B^3^ = A^^3^
J = F^2 = B^3^2 = A^^3^2
54
One thing that is often unmentioned is how to know which is the first or second parent. You can usegit logorgit show. If it's a merge commit with multiple parents, the parents will be listed in order of first, second, etc.
– wisbucky
Mar 19 '15 at 20:17
4
Why is this so hard for me to remember which one does what?! Does anybody have a memory cue or dumb saying for these? Possibly something like PECS? I tried myself but my brain keeps trying to make a relationship between caret and Carrot Top, and that is not working :(.
– mkobit
Nov 17 '15 at 18:08
34
way to remember: '~' is "fuzzy" or "approximate" (i.e., you only get the first parent) while '^' is precise (so goes through every single commit).
– bwv549
Feb 24 '16 at 21:25
4
I reply to myself: git merge branch1 branch2 branch3...
– superruzafa
Feb 20 '17 at 11:28
8
@duckx the graph is actually going top-to-bottom, so A is the most recent commit, and G is one of the oldest. The path from G to D is forward, not backward, from what I can tell.
– goldenratio
Mar 17 '17 at 18:12
|
show 8 more comments
HEAD^ means the first parent of the tip of the current branch.
Remember that git commits can have more than one parent. HEAD^ is short for HEAD^1, and you can also address HEAD^2 and so on as appropriate.
You can get to parents of any commit, not just HEAD. You can also move back through generations: for example, master~2 means the grandparent of the tip of the master branch, favoring the first parent in cases of ambiguity. These specifiers can be chained arbitrarily
, e.g., topic~3^2.
For the full details, see "Specifying Revisions" in the git rev-parse documentation.
To have a visual representation of the idea let's quote part of documentation:
Here is an illustration, by Jon Loeliger. Both commit nodes B and C are parents of commit node A. Parent commits are ordered left-to-right.
G H I J
/ /
D E F
| /
| / |
|/ |
B C
/
/
A
A = = A^0
B = A^ = A^1 = A~1
C = A^2
D = A^^ = A^1^1 = A~2
E = B^2 = A^^2
F = B^3 = A^^3
G = A^^^ = A^1^1^1 = A~3
H = D^2 = B^^2 = A^^^2 = A~2^2
I = F^ = B^3^ = A^^3^
J = F^2 = B^3^2 = A^^3^2
HEAD^ means the first parent of the tip of the current branch.
Remember that git commits can have more than one parent. HEAD^ is short for HEAD^1, and you can also address HEAD^2 and so on as appropriate.
You can get to parents of any commit, not just HEAD. You can also move back through generations: for example, master~2 means the grandparent of the tip of the master branch, favoring the first parent in cases of ambiguity. These specifiers can be chained arbitrarily
, e.g., topic~3^2.
For the full details, see "Specifying Revisions" in the git rev-parse documentation.
To have a visual representation of the idea let's quote part of documentation:
Here is an illustration, by Jon Loeliger. Both commit nodes B and C are parents of commit node A. Parent commits are ordered left-to-right.
G H I J
/ /
D E F
| /
| / |
|/ |
B C
/
/
A
A = = A^0
B = A^ = A^1 = A~1
C = A^2
D = A^^ = A^1^1 = A~2
E = B^2 = A^^2
F = B^3 = A^^3
G = A^^^ = A^1^1^1 = A~3
H = D^2 = B^^2 = A^^^2 = A~2^2
I = F^ = B^3^ = A^^3^
J = F^2 = B^3^2 = A^^3^2
edited Dec 17 '18 at 16:27
YakovL
2,929102339
2,929102339
answered Feb 8 '10 at 16:06
Greg BaconGreg Bacon
99.9k25161215
99.9k25161215
54
One thing that is often unmentioned is how to know which is the first or second parent. You can usegit logorgit show. If it's a merge commit with multiple parents, the parents will be listed in order of first, second, etc.
– wisbucky
Mar 19 '15 at 20:17
4
Why is this so hard for me to remember which one does what?! Does anybody have a memory cue or dumb saying for these? Possibly something like PECS? I tried myself but my brain keeps trying to make a relationship between caret and Carrot Top, and that is not working :(.
– mkobit
Nov 17 '15 at 18:08
34
way to remember: '~' is "fuzzy" or "approximate" (i.e., you only get the first parent) while '^' is precise (so goes through every single commit).
– bwv549
Feb 24 '16 at 21:25
4
I reply to myself: git merge branch1 branch2 branch3...
– superruzafa
Feb 20 '17 at 11:28
8
@duckx the graph is actually going top-to-bottom, so A is the most recent commit, and G is one of the oldest. The path from G to D is forward, not backward, from what I can tell.
– goldenratio
Mar 17 '17 at 18:12
|
show 8 more comments
54
One thing that is often unmentioned is how to know which is the first or second parent. You can usegit logorgit show. If it's a merge commit with multiple parents, the parents will be listed in order of first, second, etc.
– wisbucky
Mar 19 '15 at 20:17
4
Why is this so hard for me to remember which one does what?! Does anybody have a memory cue or dumb saying for these? Possibly something like PECS? I tried myself but my brain keeps trying to make a relationship between caret and Carrot Top, and that is not working :(.
– mkobit
Nov 17 '15 at 18:08
34
way to remember: '~' is "fuzzy" or "approximate" (i.e., you only get the first parent) while '^' is precise (so goes through every single commit).
– bwv549
Feb 24 '16 at 21:25
4
I reply to myself: git merge branch1 branch2 branch3...
– superruzafa
Feb 20 '17 at 11:28
8
@duckx the graph is actually going top-to-bottom, so A is the most recent commit, and G is one of the oldest. The path from G to D is forward, not backward, from what I can tell.
– goldenratio
Mar 17 '17 at 18:12
54
54
One thing that is often unmentioned is how to know which is the first or second parent. You can use
git log or git show. If it's a merge commit with multiple parents, the parents will be listed in order of first, second, etc.– wisbucky
Mar 19 '15 at 20:17
One thing that is often unmentioned is how to know which is the first or second parent. You can use
git log or git show. If it's a merge commit with multiple parents, the parents will be listed in order of first, second, etc.– wisbucky
Mar 19 '15 at 20:17
4
4
Why is this so hard for me to remember which one does what?! Does anybody have a memory cue or dumb saying for these? Possibly something like PECS? I tried myself but my brain keeps trying to make a relationship between caret and Carrot Top, and that is not working :(.
– mkobit
Nov 17 '15 at 18:08
Why is this so hard for me to remember which one does what?! Does anybody have a memory cue or dumb saying for these? Possibly something like PECS? I tried myself but my brain keeps trying to make a relationship between caret and Carrot Top, and that is not working :(.
– mkobit
Nov 17 '15 at 18:08
34
34
way to remember: '~' is "fuzzy" or "approximate" (i.e., you only get the first parent) while '^' is precise (so goes through every single commit).
– bwv549
Feb 24 '16 at 21:25
way to remember: '~' is "fuzzy" or "approximate" (i.e., you only get the first parent) while '^' is precise (so goes through every single commit).
– bwv549
Feb 24 '16 at 21:25
4
4
I reply to myself: git merge branch1 branch2 branch3...
– superruzafa
Feb 20 '17 at 11:28
I reply to myself: git merge branch1 branch2 branch3...
– superruzafa
Feb 20 '17 at 11:28
8
8
@duckx the graph is actually going top-to-bottom, so A is the most recent commit, and G is one of the oldest. The path from G to D is forward, not backward, from what I can tell.
– goldenratio
Mar 17 '17 at 18:12
@duckx the graph is actually going top-to-bottom, so A is the most recent commit, and G is one of the oldest. The path from G to D is forward, not backward, from what I can tell.
– goldenratio
Mar 17 '17 at 18:12
|
show 8 more comments
The difference between HEAD^ and HEAD~ is well described by the illustration (by Jon Loeliger) found on http://www.kernel.org/pub/software/scm/git/docs/git-rev-parse.html.
This documentation can be a bit obscure to beginners so I've reproduced that illustration below:
G H I J
/ /
D E F
| /
| / |
|/ |
B C
/
/
A
A = = A^0
B = A^ = A^1 = A~1
C = A^2
D = A^^ = A^1^1 = A~2
E = B^2 = A^^2
F = B^3 = A^^3
G = A^^^ = A^1^1^1 = A~3
H = D^2 = B^^2 = A^^^2 = A~2^2
I = F^ = B^3^ = A^^3^
J = F^2 = B^3^2 = A^^3^2
18
Seeing is understanding! Thanks for the explicit diagram.
– kontur
Jan 14 '14 at 8:55
8
Just one question. How is it possible for a commit to have more than two parents? (See B - it's parents are D, E and F) I imagine that the only way a commit can have two parents is when it is a merge commit... but how can you merge 3 commits at the same time?
– tsikov
Sep 29 '15 at 14:01
If I'm not mistaken, this may be obvious, but I think it should be specified that HEAD~ follows the current branch (like Diego Dias mentioned below).
– fibono
Oct 30 '15 at 13:40
2
Additionally,F = A^2^.
– Mateen Ulhaq
Feb 11 '16 at 20:12
1
So,^ == ^1 == LEFTMOST PARENT,^2 == SECOND LEFTMOST PARENTand so forth. And~ == ~1 == LEFTMOST PARENT,~2 == LEFTMOST PARENTS LEFTMOST PARENT == LEFTMOST GRANDPARENT. By extension,~2^2 == LEFTMOST GRANDPARENTS SECOND LEFTMOST PARENT
– Alexander Torstling
Jun 4 '18 at 19:00
|
show 1 more comment
The difference between HEAD^ and HEAD~ is well described by the illustration (by Jon Loeliger) found on http://www.kernel.org/pub/software/scm/git/docs/git-rev-parse.html.
This documentation can be a bit obscure to beginners so I've reproduced that illustration below:
G H I J
/ /
D E F
| /
| / |
|/ |
B C
/
/
A
A = = A^0
B = A^ = A^1 = A~1
C = A^2
D = A^^ = A^1^1 = A~2
E = B^2 = A^^2
F = B^3 = A^^3
G = A^^^ = A^1^1^1 = A~3
H = D^2 = B^^2 = A^^^2 = A~2^2
I = F^ = B^3^ = A^^3^
J = F^2 = B^3^2 = A^^3^2
18
Seeing is understanding! Thanks for the explicit diagram.
– kontur
Jan 14 '14 at 8:55
8
Just one question. How is it possible for a commit to have more than two parents? (See B - it's parents are D, E and F) I imagine that the only way a commit can have two parents is when it is a merge commit... but how can you merge 3 commits at the same time?
– tsikov
Sep 29 '15 at 14:01
If I'm not mistaken, this may be obvious, but I think it should be specified that HEAD~ follows the current branch (like Diego Dias mentioned below).
– fibono
Oct 30 '15 at 13:40
2
Additionally,F = A^2^.
– Mateen Ulhaq
Feb 11 '16 at 20:12
1
So,^ == ^1 == LEFTMOST PARENT,^2 == SECOND LEFTMOST PARENTand so forth. And~ == ~1 == LEFTMOST PARENT,~2 == LEFTMOST PARENTS LEFTMOST PARENT == LEFTMOST GRANDPARENT. By extension,~2^2 == LEFTMOST GRANDPARENTS SECOND LEFTMOST PARENT
– Alexander Torstling
Jun 4 '18 at 19:00
|
show 1 more comment
The difference between HEAD^ and HEAD~ is well described by the illustration (by Jon Loeliger) found on http://www.kernel.org/pub/software/scm/git/docs/git-rev-parse.html.
This documentation can be a bit obscure to beginners so I've reproduced that illustration below:
G H I J
/ /
D E F
| /
| / |
|/ |
B C
/
/
A
A = = A^0
B = A^ = A^1 = A~1
C = A^2
D = A^^ = A^1^1 = A~2
E = B^2 = A^^2
F = B^3 = A^^3
G = A^^^ = A^1^1^1 = A~3
H = D^2 = B^^2 = A^^^2 = A~2^2
I = F^ = B^3^ = A^^3^
J = F^2 = B^3^2 = A^^3^2
The difference between HEAD^ and HEAD~ is well described by the illustration (by Jon Loeliger) found on http://www.kernel.org/pub/software/scm/git/docs/git-rev-parse.html.
This documentation can be a bit obscure to beginners so I've reproduced that illustration below:
G H I J
/ /
D E F
| /
| / |
|/ |
B C
/
/
A
A = = A^0
B = A^ = A^1 = A~1
C = A^2
D = A^^ = A^1^1 = A~2
E = B^2 = A^^2
F = B^3 = A^^3
G = A^^^ = A^1^1^1 = A~3
H = D^2 = B^^2 = A^^^2 = A~2^2
I = F^ = B^3^ = A^^3^
J = F^2 = B^3^2 = A^^3^2
edited Dec 17 '18 at 16:24
YakovL
2,929102339
2,929102339
answered Sep 21 '12 at 9:11
g_fredg_fred
4,67932235
4,67932235
18
Seeing is understanding! Thanks for the explicit diagram.
– kontur
Jan 14 '14 at 8:55
8
Just one question. How is it possible for a commit to have more than two parents? (See B - it's parents are D, E and F) I imagine that the only way a commit can have two parents is when it is a merge commit... but how can you merge 3 commits at the same time?
– tsikov
Sep 29 '15 at 14:01
If I'm not mistaken, this may be obvious, but I think it should be specified that HEAD~ follows the current branch (like Diego Dias mentioned below).
– fibono
Oct 30 '15 at 13:40
2
Additionally,F = A^2^.
– Mateen Ulhaq
Feb 11 '16 at 20:12
1
So,^ == ^1 == LEFTMOST PARENT,^2 == SECOND LEFTMOST PARENTand so forth. And~ == ~1 == LEFTMOST PARENT,~2 == LEFTMOST PARENTS LEFTMOST PARENT == LEFTMOST GRANDPARENT. By extension,~2^2 == LEFTMOST GRANDPARENTS SECOND LEFTMOST PARENT
– Alexander Torstling
Jun 4 '18 at 19:00
|
show 1 more comment
18
Seeing is understanding! Thanks for the explicit diagram.
– kontur
Jan 14 '14 at 8:55
8
Just one question. How is it possible for a commit to have more than two parents? (See B - it's parents are D, E and F) I imagine that the only way a commit can have two parents is when it is a merge commit... but how can you merge 3 commits at the same time?
– tsikov
Sep 29 '15 at 14:01
If I'm not mistaken, this may be obvious, but I think it should be specified that HEAD~ follows the current branch (like Diego Dias mentioned below).
– fibono
Oct 30 '15 at 13:40
2
Additionally,F = A^2^.
– Mateen Ulhaq
Feb 11 '16 at 20:12
1
So,^ == ^1 == LEFTMOST PARENT,^2 == SECOND LEFTMOST PARENTand so forth. And~ == ~1 == LEFTMOST PARENT,~2 == LEFTMOST PARENTS LEFTMOST PARENT == LEFTMOST GRANDPARENT. By extension,~2^2 == LEFTMOST GRANDPARENTS SECOND LEFTMOST PARENT
– Alexander Torstling
Jun 4 '18 at 19:00
18
18
Seeing is understanding! Thanks for the explicit diagram.
– kontur
Jan 14 '14 at 8:55
Seeing is understanding! Thanks for the explicit diagram.
– kontur
Jan 14 '14 at 8:55
8
8
Just one question. How is it possible for a commit to have more than two parents? (See B - it's parents are D, E and F) I imagine that the only way a commit can have two parents is when it is a merge commit... but how can you merge 3 commits at the same time?
– tsikov
Sep 29 '15 at 14:01
Just one question. How is it possible for a commit to have more than two parents? (See B - it's parents are D, E and F) I imagine that the only way a commit can have two parents is when it is a merge commit... but how can you merge 3 commits at the same time?
– tsikov
Sep 29 '15 at 14:01
If I'm not mistaken, this may be obvious, but I think it should be specified that HEAD~ follows the current branch (like Diego Dias mentioned below).
– fibono
Oct 30 '15 at 13:40
If I'm not mistaken, this may be obvious, but I think it should be specified that HEAD~ follows the current branch (like Diego Dias mentioned below).
– fibono
Oct 30 '15 at 13:40
2
2
Additionally,
F = A^2^.– Mateen Ulhaq
Feb 11 '16 at 20:12
Additionally,
F = A^2^.– Mateen Ulhaq
Feb 11 '16 at 20:12
1
1
So,
^ == ^1 == LEFTMOST PARENT, ^2 == SECOND LEFTMOST PARENT and so forth. And ~ == ~1 == LEFTMOST PARENT, ~2 == LEFTMOST PARENTS LEFTMOST PARENT == LEFTMOST GRANDPARENT. By extension, ~2^2 == LEFTMOST GRANDPARENTS SECOND LEFTMOST PARENT– Alexander Torstling
Jun 4 '18 at 19:00
So,
^ == ^1 == LEFTMOST PARENT, ^2 == SECOND LEFTMOST PARENT and so forth. And ~ == ~1 == LEFTMOST PARENT, ~2 == LEFTMOST PARENTS LEFTMOST PARENT == LEFTMOST GRANDPARENT. By extension, ~2^2 == LEFTMOST GRANDPARENTS SECOND LEFTMOST PARENT– Alexander Torstling
Jun 4 '18 at 19:00
|
show 1 more comment
Both ~ and ^ on their own refer to the parent of the commit (~~ and ^^ both refer to the grandparent commit, etc.) But they differ in meaning when they are used with numbers:
~2means up two levels in the hierarchy, via the first parent if a commit has more than one parent^2means the second parent where a commit has more than one parent (i.e. because it's a merge)
These can be combined, so HEAD~2^3 means HEAD's grandparent commit's third parent commit.
1
Reading this followed by the picture from stackoverflow.com/questions/2221658/… made perfect sense.
– kunigami
Sep 7 '15 at 16:57
13
This should be the accepted answer, much more succinct and useful than the others.
– RichVel
Mar 27 '16 at 8:47
1
This answer made me distinguish between caret/tilde without number and with number! I thought^^was the same as^2but it's not .
– Alexander Derck
Oct 16 '18 at 10:44
add a comment |
Both ~ and ^ on their own refer to the parent of the commit (~~ and ^^ both refer to the grandparent commit, etc.) But they differ in meaning when they are used with numbers:
~2means up two levels in the hierarchy, via the first parent if a commit has more than one parent^2means the second parent where a commit has more than one parent (i.e. because it's a merge)
These can be combined, so HEAD~2^3 means HEAD's grandparent commit's third parent commit.
1
Reading this followed by the picture from stackoverflow.com/questions/2221658/… made perfect sense.
– kunigami
Sep 7 '15 at 16:57
13
This should be the accepted answer, much more succinct and useful than the others.
– RichVel
Mar 27 '16 at 8:47
1
This answer made me distinguish between caret/tilde without number and with number! I thought^^was the same as^2but it's not .
– Alexander Derck
Oct 16 '18 at 10:44
add a comment |
Both ~ and ^ on their own refer to the parent of the commit (~~ and ^^ both refer to the grandparent commit, etc.) But they differ in meaning when they are used with numbers:
~2means up two levels in the hierarchy, via the first parent if a commit has more than one parent^2means the second parent where a commit has more than one parent (i.e. because it's a merge)
These can be combined, so HEAD~2^3 means HEAD's grandparent commit's third parent commit.
Both ~ and ^ on their own refer to the parent of the commit (~~ and ^^ both refer to the grandparent commit, etc.) But they differ in meaning when they are used with numbers:
~2means up two levels in the hierarchy, via the first parent if a commit has more than one parent^2means the second parent where a commit has more than one parent (i.e. because it's a merge)
These can be combined, so HEAD~2^3 means HEAD's grandparent commit's third parent commit.
edited Aug 8 '14 at 9:37
answered May 17 '14 at 18:55
Matthew StrawbridgeMatthew Strawbridge
14.8k105279
14.8k105279
1
Reading this followed by the picture from stackoverflow.com/questions/2221658/… made perfect sense.
– kunigami
Sep 7 '15 at 16:57
13
This should be the accepted answer, much more succinct and useful than the others.
– RichVel
Mar 27 '16 at 8:47
1
This answer made me distinguish between caret/tilde without number and with number! I thought^^was the same as^2but it's not .
– Alexander Derck
Oct 16 '18 at 10:44
add a comment |
1
Reading this followed by the picture from stackoverflow.com/questions/2221658/… made perfect sense.
– kunigami
Sep 7 '15 at 16:57
13
This should be the accepted answer, much more succinct and useful than the others.
– RichVel
Mar 27 '16 at 8:47
1
This answer made me distinguish between caret/tilde without number and with number! I thought^^was the same as^2but it's not .
– Alexander Derck
Oct 16 '18 at 10:44
1
1
Reading this followed by the picture from stackoverflow.com/questions/2221658/… made perfect sense.
– kunigami
Sep 7 '15 at 16:57
Reading this followed by the picture from stackoverflow.com/questions/2221658/… made perfect sense.
– kunigami
Sep 7 '15 at 16:57
13
13
This should be the accepted answer, much more succinct and useful than the others.
– RichVel
Mar 27 '16 at 8:47
This should be the accepted answer, much more succinct and useful than the others.
– RichVel
Mar 27 '16 at 8:47
1
1
This answer made me distinguish between caret/tilde without number and with number! I thought
^^ was the same as ^2 but it's not .– Alexander Derck
Oct 16 '18 at 10:44
This answer made me distinguish between caret/tilde without number and with number! I thought
^^ was the same as ^2 but it's not .– Alexander Derck
Oct 16 '18 at 10:44
add a comment |
My two cents...

And howH=A~2^2notH=A~2^1?
– Mohammad Faisal
Dec 10 '18 at 14:11
If I had figured it out correctly, the commitsA,B,D,Gare on the same branch and the commitDis a merge ofGandH, therefore having two parents. So the commit (H) from other branch is reference by^2.
– Mohammad Faisal
Dec 10 '18 at 14:27
add a comment |
My two cents...

And howH=A~2^2notH=A~2^1?
– Mohammad Faisal
Dec 10 '18 at 14:11
If I had figured it out correctly, the commitsA,B,D,Gare on the same branch and the commitDis a merge ofGandH, therefore having two parents. So the commit (H) from other branch is reference by^2.
– Mohammad Faisal
Dec 10 '18 at 14:27
add a comment |
My two cents...

My two cents...

edited Feb 1 '18 at 22:57
Mark Amery
60.9k31243292
60.9k31243292
answered Mar 18 '15 at 11:30
Alex JanzikAlex Janzik
2,85611516
2,85611516
And howH=A~2^2notH=A~2^1?
– Mohammad Faisal
Dec 10 '18 at 14:11
If I had figured it out correctly, the commitsA,B,D,Gare on the same branch and the commitDis a merge ofGandH, therefore having two parents. So the commit (H) from other branch is reference by^2.
– Mohammad Faisal
Dec 10 '18 at 14:27
add a comment |
And howH=A~2^2notH=A~2^1?
– Mohammad Faisal
Dec 10 '18 at 14:11
If I had figured it out correctly, the commitsA,B,D,Gare on the same branch and the commitDis a merge ofGandH, therefore having two parents. So the commit (H) from other branch is reference by^2.
– Mohammad Faisal
Dec 10 '18 at 14:27
And how
H=A~2^2 not H=A~2^1?– Mohammad Faisal
Dec 10 '18 at 14:11
And how
H=A~2^2 not H=A~2^1?– Mohammad Faisal
Dec 10 '18 at 14:11
If I had figured it out correctly, the commits
A, B, D, G are on the same branch and the commit D is a merge of G and H, therefore having two parents. So the commit (H) from other branch is reference by ^2.– Mohammad Faisal
Dec 10 '18 at 14:27
If I had figured it out correctly, the commits
A, B, D, G are on the same branch and the commit D is a merge of G and H, therefore having two parents. So the commit (H) from other branch is reference by ^2.– Mohammad Faisal
Dec 10 '18 at 14:27
add a comment |
Here's a very good explanation taken verbatim from http://www.paulboxley.com/blog/2011/06/git-caret-and-tilde :
ref~is shorthand forref~1and means the commit's first parent.ref~2means the commit's first parent's first parent.ref~3means the commit's first parent's first parent's first parent. And so on.
ref^is shorthand forref^1and means the commit's first parent. But where the two differ is thatref^2means the commit's second parent (remember, commits can have two parents when they are a merge).
The
^and~operators can be combined.

add a comment |
Here's a very good explanation taken verbatim from http://www.paulboxley.com/blog/2011/06/git-caret-and-tilde :
ref~is shorthand forref~1and means the commit's first parent.ref~2means the commit's first parent's first parent.ref~3means the commit's first parent's first parent's first parent. And so on.
ref^is shorthand forref^1and means the commit's first parent. But where the two differ is thatref^2means the commit's second parent (remember, commits can have two parents when they are a merge).
The
^and~operators can be combined.

add a comment |
Here's a very good explanation taken verbatim from http://www.paulboxley.com/blog/2011/06/git-caret-and-tilde :
ref~is shorthand forref~1and means the commit's first parent.ref~2means the commit's first parent's first parent.ref~3means the commit's first parent's first parent's first parent. And so on.
ref^is shorthand forref^1and means the commit's first parent. But where the two differ is thatref^2means the commit's second parent (remember, commits can have two parents when they are a merge).
The
^and~operators can be combined.

Here's a very good explanation taken verbatim from http://www.paulboxley.com/blog/2011/06/git-caret-and-tilde :
ref~is shorthand forref~1and means the commit's first parent.ref~2means the commit's first parent's first parent.ref~3means the commit's first parent's first parent's first parent. And so on.
ref^is shorthand forref^1and means the commit's first parent. But where the two differ is thatref^2means the commit's second parent (remember, commits can have two parents when they are a merge).
The
^and~operators can be combined.

answered Mar 27 '17 at 12:24
dr01dr01
1,33911126
1,33911126
add a comment |
add a comment |
The ^<n> format allows you to select the nth parent of the commit (relevant in merges). The ~<n> format allows you to select the nth ancestor commit, always following the first parent. See git-rev-parse's documentation for some examples.
add a comment |
The ^<n> format allows you to select the nth parent of the commit (relevant in merges). The ~<n> format allows you to select the nth ancestor commit, always following the first parent. See git-rev-parse's documentation for some examples.
add a comment |
The ^<n> format allows you to select the nth parent of the commit (relevant in merges). The ~<n> format allows you to select the nth ancestor commit, always following the first parent. See git-rev-parse's documentation for some examples.
The ^<n> format allows you to select the nth parent of the commit (relevant in merges). The ~<n> format allows you to select the nth ancestor commit, always following the first parent. See git-rev-parse's documentation for some examples.
edited Mar 29 '12 at 7:47
answered Feb 8 '10 at 13:03
jamessanjamessan
32.1k77075
32.1k77075
add a comment |
add a comment |
It is worth noting that git also has a syntax for tracking "from-where-you-came"/"want-to-go-back-now" - for example, HEAD@{1} will reference the place from where you jumped to new commit location.
Basically HEAD@{} variables capture the history of HEAD movement, and you can decide to use a particular head by looking into reflogs of git using the command git reflog.
Example:
0aee51f HEAD@{0}: reset: moving to HEAD@{5}
290e035 HEAD@{1}: reset: moving to HEAD@{7}
0aee51f HEAD@{2}: reset: moving to HEAD@{3}
290e035 HEAD@{3}: reset: moving to HEAD@{3}
9e77426 HEAD@{4}: reset: moving to HEAD@{3}
290e035 HEAD@{5}: reset: moving to HEAD@{3}
0aee51f HEAD@{6}: reset: moving to HEAD@{3}
290e035 HEAD@{7}: reset: moving to HEAD@{3}
9e77426 HEAD@{8}: reset: moving to HEAD@{3}
290e035 HEAD@{9}: reset: moving to HEAD@{1}
0aee51f HEAD@{10}: reset: moving to HEAD@{4}
290e035 HEAD@{11}: reset: moving to HEAD^
9e77426 HEAD@{12}: reset: moving to HEAD^
eb48179 HEAD@{13}: reset: moving to HEAD~
f916d93 HEAD@{14}: reset: moving to HEAD~
0aee51f HEAD@{15}: reset: moving to HEAD@{5}
f19fd9b HEAD@{16}: reset: moving to HEAD~1
290e035 HEAD@{17}: reset: moving to HEAD~2
eb48179 HEAD@{18}: reset: moving to HEAD~2
0aee51f HEAD@{19}: reset: moving to HEAD@{5}
eb48179 HEAD@{20}: reset: moving to HEAD~2
0aee51f HEAD@{21}: reset: moving to HEAD@{1}
f916d93 HEAD@{22}: reset: moving to HEAD@{1}
0aee51f HEAD@{23}: reset: moving to HEAD@{1}
f916d93 HEAD@{24}: reset: moving to HEAD^
0aee51f HEAD@{25}: commit (amend): 3rd commmit
35a7332 HEAD@{26}: checkout: moving from temp2_new_br to temp2_new_br
35a7332 HEAD@{27}: commit (amend): 3rd commmit
72c0be8 HEAD@{28}: commit (amend): 3rd commmit
An example could be that I did local-commits a->b->c->d and then I went back discarding 2 commits to check my code - git reset HEAD~2 - and then after that I want to move my HEAD back to d - git reset HEAD@{1}.
add a comment |
It is worth noting that git also has a syntax for tracking "from-where-you-came"/"want-to-go-back-now" - for example, HEAD@{1} will reference the place from where you jumped to new commit location.
Basically HEAD@{} variables capture the history of HEAD movement, and you can decide to use a particular head by looking into reflogs of git using the command git reflog.
Example:
0aee51f HEAD@{0}: reset: moving to HEAD@{5}
290e035 HEAD@{1}: reset: moving to HEAD@{7}
0aee51f HEAD@{2}: reset: moving to HEAD@{3}
290e035 HEAD@{3}: reset: moving to HEAD@{3}
9e77426 HEAD@{4}: reset: moving to HEAD@{3}
290e035 HEAD@{5}: reset: moving to HEAD@{3}
0aee51f HEAD@{6}: reset: moving to HEAD@{3}
290e035 HEAD@{7}: reset: moving to HEAD@{3}
9e77426 HEAD@{8}: reset: moving to HEAD@{3}
290e035 HEAD@{9}: reset: moving to HEAD@{1}
0aee51f HEAD@{10}: reset: moving to HEAD@{4}
290e035 HEAD@{11}: reset: moving to HEAD^
9e77426 HEAD@{12}: reset: moving to HEAD^
eb48179 HEAD@{13}: reset: moving to HEAD~
f916d93 HEAD@{14}: reset: moving to HEAD~
0aee51f HEAD@{15}: reset: moving to HEAD@{5}
f19fd9b HEAD@{16}: reset: moving to HEAD~1
290e035 HEAD@{17}: reset: moving to HEAD~2
eb48179 HEAD@{18}: reset: moving to HEAD~2
0aee51f HEAD@{19}: reset: moving to HEAD@{5}
eb48179 HEAD@{20}: reset: moving to HEAD~2
0aee51f HEAD@{21}: reset: moving to HEAD@{1}
f916d93 HEAD@{22}: reset: moving to HEAD@{1}
0aee51f HEAD@{23}: reset: moving to HEAD@{1}
f916d93 HEAD@{24}: reset: moving to HEAD^
0aee51f HEAD@{25}: commit (amend): 3rd commmit
35a7332 HEAD@{26}: checkout: moving from temp2_new_br to temp2_new_br
35a7332 HEAD@{27}: commit (amend): 3rd commmit
72c0be8 HEAD@{28}: commit (amend): 3rd commmit
An example could be that I did local-commits a->b->c->d and then I went back discarding 2 commits to check my code - git reset HEAD~2 - and then after that I want to move my HEAD back to d - git reset HEAD@{1}.
add a comment |
It is worth noting that git also has a syntax for tracking "from-where-you-came"/"want-to-go-back-now" - for example, HEAD@{1} will reference the place from where you jumped to new commit location.
Basically HEAD@{} variables capture the history of HEAD movement, and you can decide to use a particular head by looking into reflogs of git using the command git reflog.
Example:
0aee51f HEAD@{0}: reset: moving to HEAD@{5}
290e035 HEAD@{1}: reset: moving to HEAD@{7}
0aee51f HEAD@{2}: reset: moving to HEAD@{3}
290e035 HEAD@{3}: reset: moving to HEAD@{3}
9e77426 HEAD@{4}: reset: moving to HEAD@{3}
290e035 HEAD@{5}: reset: moving to HEAD@{3}
0aee51f HEAD@{6}: reset: moving to HEAD@{3}
290e035 HEAD@{7}: reset: moving to HEAD@{3}
9e77426 HEAD@{8}: reset: moving to HEAD@{3}
290e035 HEAD@{9}: reset: moving to HEAD@{1}
0aee51f HEAD@{10}: reset: moving to HEAD@{4}
290e035 HEAD@{11}: reset: moving to HEAD^
9e77426 HEAD@{12}: reset: moving to HEAD^
eb48179 HEAD@{13}: reset: moving to HEAD~
f916d93 HEAD@{14}: reset: moving to HEAD~
0aee51f HEAD@{15}: reset: moving to HEAD@{5}
f19fd9b HEAD@{16}: reset: moving to HEAD~1
290e035 HEAD@{17}: reset: moving to HEAD~2
eb48179 HEAD@{18}: reset: moving to HEAD~2
0aee51f HEAD@{19}: reset: moving to HEAD@{5}
eb48179 HEAD@{20}: reset: moving to HEAD~2
0aee51f HEAD@{21}: reset: moving to HEAD@{1}
f916d93 HEAD@{22}: reset: moving to HEAD@{1}
0aee51f HEAD@{23}: reset: moving to HEAD@{1}
f916d93 HEAD@{24}: reset: moving to HEAD^
0aee51f HEAD@{25}: commit (amend): 3rd commmit
35a7332 HEAD@{26}: checkout: moving from temp2_new_br to temp2_new_br
35a7332 HEAD@{27}: commit (amend): 3rd commmit
72c0be8 HEAD@{28}: commit (amend): 3rd commmit
An example could be that I did local-commits a->b->c->d and then I went back discarding 2 commits to check my code - git reset HEAD~2 - and then after that I want to move my HEAD back to d - git reset HEAD@{1}.
It is worth noting that git also has a syntax for tracking "from-where-you-came"/"want-to-go-back-now" - for example, HEAD@{1} will reference the place from where you jumped to new commit location.
Basically HEAD@{} variables capture the history of HEAD movement, and you can decide to use a particular head by looking into reflogs of git using the command git reflog.
Example:
0aee51f HEAD@{0}: reset: moving to HEAD@{5}
290e035 HEAD@{1}: reset: moving to HEAD@{7}
0aee51f HEAD@{2}: reset: moving to HEAD@{3}
290e035 HEAD@{3}: reset: moving to HEAD@{3}
9e77426 HEAD@{4}: reset: moving to HEAD@{3}
290e035 HEAD@{5}: reset: moving to HEAD@{3}
0aee51f HEAD@{6}: reset: moving to HEAD@{3}
290e035 HEAD@{7}: reset: moving to HEAD@{3}
9e77426 HEAD@{8}: reset: moving to HEAD@{3}
290e035 HEAD@{9}: reset: moving to HEAD@{1}
0aee51f HEAD@{10}: reset: moving to HEAD@{4}
290e035 HEAD@{11}: reset: moving to HEAD^
9e77426 HEAD@{12}: reset: moving to HEAD^
eb48179 HEAD@{13}: reset: moving to HEAD~
f916d93 HEAD@{14}: reset: moving to HEAD~
0aee51f HEAD@{15}: reset: moving to HEAD@{5}
f19fd9b HEAD@{16}: reset: moving to HEAD~1
290e035 HEAD@{17}: reset: moving to HEAD~2
eb48179 HEAD@{18}: reset: moving to HEAD~2
0aee51f HEAD@{19}: reset: moving to HEAD@{5}
eb48179 HEAD@{20}: reset: moving to HEAD~2
0aee51f HEAD@{21}: reset: moving to HEAD@{1}
f916d93 HEAD@{22}: reset: moving to HEAD@{1}
0aee51f HEAD@{23}: reset: moving to HEAD@{1}
f916d93 HEAD@{24}: reset: moving to HEAD^
0aee51f HEAD@{25}: commit (amend): 3rd commmit
35a7332 HEAD@{26}: checkout: moving from temp2_new_br to temp2_new_br
35a7332 HEAD@{27}: commit (amend): 3rd commmit
72c0be8 HEAD@{28}: commit (amend): 3rd commmit
An example could be that I did local-commits a->b->c->d and then I went back discarding 2 commits to check my code - git reset HEAD~2 - and then after that I want to move my HEAD back to d - git reset HEAD@{1}.
edited Oct 19 '15 at 17:54
Air
5,18723767
5,18723767
answered Feb 20 '14 at 14:49
ashishashish
17816
17816
add a comment |
add a comment |
HEAD^^^ is the same as HEAD~3, selecting the third commit before HEAD
HEAD^2 specifies the second head in a merge commit
add a comment |
HEAD^^^ is the same as HEAD~3, selecting the third commit before HEAD
HEAD^2 specifies the second head in a merge commit
add a comment |
HEAD^^^ is the same as HEAD~3, selecting the third commit before HEAD
HEAD^2 specifies the second head in a merge commit
HEAD^^^ is the same as HEAD~3, selecting the third commit before HEAD
HEAD^2 specifies the second head in a merge commit
answered Feb 8 '10 at 13:01
knittlknittl
151k39228281
151k39228281
add a comment |
add a comment |
HEAD~ specifies the first parent on a "branch"
HEAD^ allows you to select a specific parent of the commit
An Example:
If you want to follow a side branch, you have to specify something like
master~209^2~15
add a comment |
HEAD~ specifies the first parent on a "branch"
HEAD^ allows you to select a specific parent of the commit
An Example:
If you want to follow a side branch, you have to specify something like
master~209^2~15
add a comment |
HEAD~ specifies the first parent on a "branch"
HEAD^ allows you to select a specific parent of the commit
An Example:
If you want to follow a side branch, you have to specify something like
master~209^2~15
HEAD~ specifies the first parent on a "branch"
HEAD^ allows you to select a specific parent of the commit
An Example:
If you want to follow a side branch, you have to specify something like
master~209^2~15
edited Nov 8 '11 at 22:51
meagar♦
178k29272288
178k29272288
answered Feb 8 '10 at 13:05
Diego DiasDiego Dias
15.5k52734
15.5k52734
add a comment |
add a comment |
TLDR
~ is what you want most of the time, it references past commits to the current branch
^ references parents (git-merge creates a 2nd parent or more)
A~ is always the same as A^
A~~ is always the same as A^^, and so on
A~2 is not the same as A^2 however,
because ~2 is shorthand for ~~
while ^2 is not shorthand for anything, it means the 2nd parent
add a comment |
TLDR
~ is what you want most of the time, it references past commits to the current branch
^ references parents (git-merge creates a 2nd parent or more)
A~ is always the same as A^
A~~ is always the same as A^^, and so on
A~2 is not the same as A^2 however,
because ~2 is shorthand for ~~
while ^2 is not shorthand for anything, it means the 2nd parent
add a comment |
TLDR
~ is what you want most of the time, it references past commits to the current branch
^ references parents (git-merge creates a 2nd parent or more)
A~ is always the same as A^
A~~ is always the same as A^^, and so on
A~2 is not the same as A^2 however,
because ~2 is shorthand for ~~
while ^2 is not shorthand for anything, it means the 2nd parent
TLDR
~ is what you want most of the time, it references past commits to the current branch
^ references parents (git-merge creates a 2nd parent or more)
A~ is always the same as A^
A~~ is always the same as A^^, and so on
A~2 is not the same as A^2 however,
because ~2 is shorthand for ~~
while ^2 is not shorthand for anything, it means the 2nd parent
answered Jan 26 '18 at 16:36
WeakPointerWeakPointer
1,5381412
1,5381412
add a comment |
add a comment |
Simplistically:
~specifies ancestors
^specifies parents
You can specify one or more branches when merging. Then a commit has two or more parents and then ^ is useful to indicate parents.
Suppose you are on branch A and you have two more branches: B and C.
On each branch the three last commits are:
A: A1, A2, A3
B: B1, B2, B3
C: C1, C3, C3
If now on branch A you execute the command:
git merge B C
then you are combining three branches together (here your merge commit has three parents)
and
~ indicates the n'th ancestor in the first branch, so
HEAD~indicates A3
HEAD~2indicates A2
HEAD~3indicates A1
^ indicates the n'th parent, so
HEAD^indicates A3
HEAD^2indicates B3
HEAD^3indicates C3
The next use of ~ or ^ next to each other is in the context of the commit designated by previous characters.
Notice 1:
HEAD~3is always equal to:HEAD~~~and to:HEAD^^^(every indicates A1),
and generally:
HEAD~nis always equal to:HEAD~...~(n times~) and to:HEAD^...^(n times^).
Notice 2:
HEAD^3is not the same asHEAD^^^(the first indicates C3 and the second indicates A1),
and generally:
HEAD^1is the same asHEAD^,- but for n > 1:
HEAD^nis always not the same asHEAD^...^(n times~).
add a comment |
Simplistically:
~specifies ancestors
^specifies parents
You can specify one or more branches when merging. Then a commit has two or more parents and then ^ is useful to indicate parents.
Suppose you are on branch A and you have two more branches: B and C.
On each branch the three last commits are:
A: A1, A2, A3
B: B1, B2, B3
C: C1, C3, C3
If now on branch A you execute the command:
git merge B C
then you are combining three branches together (here your merge commit has three parents)
and
~ indicates the n'th ancestor in the first branch, so
HEAD~indicates A3
HEAD~2indicates A2
HEAD~3indicates A1
^ indicates the n'th parent, so
HEAD^indicates A3
HEAD^2indicates B3
HEAD^3indicates C3
The next use of ~ or ^ next to each other is in the context of the commit designated by previous characters.
Notice 1:
HEAD~3is always equal to:HEAD~~~and to:HEAD^^^(every indicates A1),
and generally:
HEAD~nis always equal to:HEAD~...~(n times~) and to:HEAD^...^(n times^).
Notice 2:
HEAD^3is not the same asHEAD^^^(the first indicates C3 and the second indicates A1),
and generally:
HEAD^1is the same asHEAD^,- but for n > 1:
HEAD^nis always not the same asHEAD^...^(n times~).
add a comment |
Simplistically:
~specifies ancestors
^specifies parents
You can specify one or more branches when merging. Then a commit has two or more parents and then ^ is useful to indicate parents.
Suppose you are on branch A and you have two more branches: B and C.
On each branch the three last commits are:
A: A1, A2, A3
B: B1, B2, B3
C: C1, C3, C3
If now on branch A you execute the command:
git merge B C
then you are combining three branches together (here your merge commit has three parents)
and
~ indicates the n'th ancestor in the first branch, so
HEAD~indicates A3
HEAD~2indicates A2
HEAD~3indicates A1
^ indicates the n'th parent, so
HEAD^indicates A3
HEAD^2indicates B3
HEAD^3indicates C3
The next use of ~ or ^ next to each other is in the context of the commit designated by previous characters.
Notice 1:
HEAD~3is always equal to:HEAD~~~and to:HEAD^^^(every indicates A1),
and generally:
HEAD~nis always equal to:HEAD~...~(n times~) and to:HEAD^...^(n times^).
Notice 2:
HEAD^3is not the same asHEAD^^^(the first indicates C3 and the second indicates A1),
and generally:
HEAD^1is the same asHEAD^,- but for n > 1:
HEAD^nis always not the same asHEAD^...^(n times~).
Simplistically:
~specifies ancestors
^specifies parents
You can specify one or more branches when merging. Then a commit has two or more parents and then ^ is useful to indicate parents.
Suppose you are on branch A and you have two more branches: B and C.
On each branch the three last commits are:
A: A1, A2, A3
B: B1, B2, B3
C: C1, C3, C3
If now on branch A you execute the command:
git merge B C
then you are combining three branches together (here your merge commit has three parents)
and
~ indicates the n'th ancestor in the first branch, so
HEAD~indicates A3
HEAD~2indicates A2
HEAD~3indicates A1
^ indicates the n'th parent, so
HEAD^indicates A3
HEAD^2indicates B3
HEAD^3indicates C3
The next use of ~ or ^ next to each other is in the context of the commit designated by previous characters.
Notice 1:
HEAD~3is always equal to:HEAD~~~and to:HEAD^^^(every indicates A1),
and generally:
HEAD~nis always equal to:HEAD~...~(n times~) and to:HEAD^...^(n times^).
Notice 2:
HEAD^3is not the same asHEAD^^^(the first indicates C3 and the second indicates A1),
and generally:
HEAD^1is the same asHEAD^,- but for n > 1:
HEAD^nis always not the same asHEAD^...^(n times~).
edited Nov 4 '18 at 2:45
Rob Bednark
10.3k125482
10.3k125482
answered Aug 28 '17 at 9:55
simhumilecosimhumileco
6,61935046
6,61935046
add a comment |
add a comment |
actual example of the difference between HEAD~ and HEAD^

add a comment |
actual example of the difference between HEAD~ and HEAD^

add a comment |
actual example of the difference between HEAD~ and HEAD^

actual example of the difference between HEAD~ and HEAD^

answered Aug 4 '18 at 6:36
Anas AlpureAnas Alpure
211
211
add a comment |
add a comment |
Simply put, for the first level of parentage (ancestry, inheritance, lineage, etc.) HEAD^ and HEAD~ both point to the same commit, which is (located) one parent above the HEAD (commit).
Furthermore, HEAD^ = HEAD^1 = HEAD~ = HEAD~1. But HEAD^^ != HEAD^2 != HEAD~2. Yet HEAD^^ = HEAD~2. Read on.
Beyond the first level of parentage, things get trickier, especially if the working branch/master branch has had merges (from other branches). There is also the matter of syntax with the caret, HEAD^^ = HEAD~2 (they're equivalent) BUT HEAD^^ != HEAD^2 (they're two different things entirely).
Each/the caret refers to the HEAD's first parent, which is why carets stringed together are equivalent to tilde expressions, because they refer to the first parent's (first parent's) first parents, etc., etc. based strictly on the number on connected carets or on the number following the tilde (either way, they both mean the same thing), i.e. stay with the first parent and go up x generations.
HEAD~2 (or HEAD^^) refers to the commit that is two levels of ancestry up/above the current commit (the HEAD) in the hierarchy, meaning the HEAD's grandparent commit.
HEAD^2, on the other hand, refers NOT to the first parent's second parent's commit, but simply to the second parent's commit. That is because the caret means the parent of the commit, and the number following signifies which/what parent commit is referred to (the first parent, in the case when the caret is not followed by a number [because it is shorthand for the number being 1, meaning the first parent]). Unlike the caret, the number that follows afterwards does not imply another level of hierarchy upwards, but rather it implies how many levels sideways, into the hierarchy, one needs to go find the correct parent (commit). Unlike the number in a tilde expression, it is only one parent up in the hierarchy, regardless of the number (immediately) proceeding the caret. Instead of upward, the caret's trailing number counts sideways for parents across the hierarchy [at a level of parents upwards that is equivalent to the number of consecutive carets].
So HEAD^3 is equal to the third parent of the HEAD commit (NOT the great-grandparent, which is what HEAD^^^ AND HEAD~3 would be...).
add a comment |
Simply put, for the first level of parentage (ancestry, inheritance, lineage, etc.) HEAD^ and HEAD~ both point to the same commit, which is (located) one parent above the HEAD (commit).
Furthermore, HEAD^ = HEAD^1 = HEAD~ = HEAD~1. But HEAD^^ != HEAD^2 != HEAD~2. Yet HEAD^^ = HEAD~2. Read on.
Beyond the first level of parentage, things get trickier, especially if the working branch/master branch has had merges (from other branches). There is also the matter of syntax with the caret, HEAD^^ = HEAD~2 (they're equivalent) BUT HEAD^^ != HEAD^2 (they're two different things entirely).
Each/the caret refers to the HEAD's first parent, which is why carets stringed together are equivalent to tilde expressions, because they refer to the first parent's (first parent's) first parents, etc., etc. based strictly on the number on connected carets or on the number following the tilde (either way, they both mean the same thing), i.e. stay with the first parent and go up x generations.
HEAD~2 (or HEAD^^) refers to the commit that is two levels of ancestry up/above the current commit (the HEAD) in the hierarchy, meaning the HEAD's grandparent commit.
HEAD^2, on the other hand, refers NOT to the first parent's second parent's commit, but simply to the second parent's commit. That is because the caret means the parent of the commit, and the number following signifies which/what parent commit is referred to (the first parent, in the case when the caret is not followed by a number [because it is shorthand for the number being 1, meaning the first parent]). Unlike the caret, the number that follows afterwards does not imply another level of hierarchy upwards, but rather it implies how many levels sideways, into the hierarchy, one needs to go find the correct parent (commit). Unlike the number in a tilde expression, it is only one parent up in the hierarchy, regardless of the number (immediately) proceeding the caret. Instead of upward, the caret's trailing number counts sideways for parents across the hierarchy [at a level of parents upwards that is equivalent to the number of consecutive carets].
So HEAD^3 is equal to the third parent of the HEAD commit (NOT the great-grandparent, which is what HEAD^^^ AND HEAD~3 would be...).
add a comment |
Simply put, for the first level of parentage (ancestry, inheritance, lineage, etc.) HEAD^ and HEAD~ both point to the same commit, which is (located) one parent above the HEAD (commit).
Furthermore, HEAD^ = HEAD^1 = HEAD~ = HEAD~1. But HEAD^^ != HEAD^2 != HEAD~2. Yet HEAD^^ = HEAD~2. Read on.
Beyond the first level of parentage, things get trickier, especially if the working branch/master branch has had merges (from other branches). There is also the matter of syntax with the caret, HEAD^^ = HEAD~2 (they're equivalent) BUT HEAD^^ != HEAD^2 (they're two different things entirely).
Each/the caret refers to the HEAD's first parent, which is why carets stringed together are equivalent to tilde expressions, because they refer to the first parent's (first parent's) first parents, etc., etc. based strictly on the number on connected carets or on the number following the tilde (either way, they both mean the same thing), i.e. stay with the first parent and go up x generations.
HEAD~2 (or HEAD^^) refers to the commit that is two levels of ancestry up/above the current commit (the HEAD) in the hierarchy, meaning the HEAD's grandparent commit.
HEAD^2, on the other hand, refers NOT to the first parent's second parent's commit, but simply to the second parent's commit. That is because the caret means the parent of the commit, and the number following signifies which/what parent commit is referred to (the first parent, in the case when the caret is not followed by a number [because it is shorthand for the number being 1, meaning the first parent]). Unlike the caret, the number that follows afterwards does not imply another level of hierarchy upwards, but rather it implies how many levels sideways, into the hierarchy, one needs to go find the correct parent (commit). Unlike the number in a tilde expression, it is only one parent up in the hierarchy, regardless of the number (immediately) proceeding the caret. Instead of upward, the caret's trailing number counts sideways for parents across the hierarchy [at a level of parents upwards that is equivalent to the number of consecutive carets].
So HEAD^3 is equal to the third parent of the HEAD commit (NOT the great-grandparent, which is what HEAD^^^ AND HEAD~3 would be...).
Simply put, for the first level of parentage (ancestry, inheritance, lineage, etc.) HEAD^ and HEAD~ both point to the same commit, which is (located) one parent above the HEAD (commit).
Furthermore, HEAD^ = HEAD^1 = HEAD~ = HEAD~1. But HEAD^^ != HEAD^2 != HEAD~2. Yet HEAD^^ = HEAD~2. Read on.
Beyond the first level of parentage, things get trickier, especially if the working branch/master branch has had merges (from other branches). There is also the matter of syntax with the caret, HEAD^^ = HEAD~2 (they're equivalent) BUT HEAD^^ != HEAD^2 (they're two different things entirely).
Each/the caret refers to the HEAD's first parent, which is why carets stringed together are equivalent to tilde expressions, because they refer to the first parent's (first parent's) first parents, etc., etc. based strictly on the number on connected carets or on the number following the tilde (either way, they both mean the same thing), i.e. stay with the first parent and go up x generations.
HEAD~2 (or HEAD^^) refers to the commit that is two levels of ancestry up/above the current commit (the HEAD) in the hierarchy, meaning the HEAD's grandparent commit.
HEAD^2, on the other hand, refers NOT to the first parent's second parent's commit, but simply to the second parent's commit. That is because the caret means the parent of the commit, and the number following signifies which/what parent commit is referred to (the first parent, in the case when the caret is not followed by a number [because it is shorthand for the number being 1, meaning the first parent]). Unlike the caret, the number that follows afterwards does not imply another level of hierarchy upwards, but rather it implies how many levels sideways, into the hierarchy, one needs to go find the correct parent (commit). Unlike the number in a tilde expression, it is only one parent up in the hierarchy, regardless of the number (immediately) proceeding the caret. Instead of upward, the caret's trailing number counts sideways for parents across the hierarchy [at a level of parents upwards that is equivalent to the number of consecutive carets].
So HEAD^3 is equal to the third parent of the HEAD commit (NOT the great-grandparent, which is what HEAD^^^ AND HEAD~3 would be...).
answered Aug 28 '17 at 17:39
Sean Tank GarveySean Tank Garvey
496
496
add a comment |
add a comment |
Thanks for contributing an answer to Stack Overflow!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f2221658%2fwhats-the-difference-between-head-and-head-in-git%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
37
it is bad to paste links, i know but this is the best explanation I found and there is picture in it. paulboxley.com/blog/2011/06/git-caret-and-tilde
– igor
Nov 13 '13 at 16:38
3
Links are especially bad when they are broken. That is the reason why it is safer to answer the question which help prevent this because of the ability to copy paste some explanations :)
– Samuel
Aug 16 '17 at 11:39