1
  1. Created a repo on Github (initialized with a readme).
  2. Cloned it with Egit.
  3. Saw that FETCH_HEAD and HEAD were checked out.
  4. Went to Github and made a change to the readme.
  5. Fetched the change.
  6. Saw that HEAD was checked out, FETCH_HEAD wasn't. But FETCH_HEAD did have the readme update. The tracking branch for origin/master also had the update.
  7. Merged the tracking branch for origin/master into my local master.
  8. Saw that both FETCH_HEAD and HEAD were checked out again.

FETCH_HEAD

According to this post: What does FETCH_HEAD in Git mean?

FETCH_HEAD is a short-lived ref, to keep track of what has just been fetched from the remote repository.

Why isn't FETCH_HEAD checked out right after fetching? Why did it only become checked out after I merged the origin's tracking branch into my local master?

Community
  • 1
  • 1
mike
  • 1,135
  • 4
  • 22
  • 39

1 Answers1

0

Why isn't FETCH_HEAD checked out right after fetching? Why did it only become checked out after I merged the origin's tracking branch into my local master?

FETCH_HEAD in itself doesn't reference any branch: it only remember the last fetched SHA1.
As it doesn't reference a branch, it isn't really checked out (and shouldn't be checked out), or you would end up with a detached head.

However, merging the tracking branch to the master branch will update HEAD (which points to the updated master): that branch is checked out.
If the merge is a "fast-forward" one, the checked-out branch HEAD and FETCH-HEAD would reference the same SHA1, giving the impression that FETCH_HEAD is "checked out" (it isn't really)

In other words, in the following picture:

checked out in Egit

FETCH_HEAD has the "checked-out" tick only because it reference the same SHA1 than the current checked-out branch HEAD (here master).

That means that, if you do a new commit:

  • FETCH_HEAD wouldn't have the checked-out tick anymore (it would still reference the last fetched SHA1). That is why I say it isn't "really" checked-out (in the sense of "it wouldn't stay checked-out after a new commit, since it is a fixed reference to a particular SHA1)
  • HEAD and the master branch would reference a new SHA1, and would keep the checked-out tick.

But if you were to check out directly the FETCH_HEAD SHA1 (before merging it to master: the Egit User Guide mentions you can do that if the reference isn't already checked-out), then:

  • FETCH_HEAD would still be "checked-out"
  • same for HEAD
  • but master (or any other branch) would not be checked-out anymore: this is a DETACHED HEAD situation

If you were to make a new commit on top of a checked-out FETCH_HEAD:

  • FETCH_HEAD would no longer be checked-out (since it remains fixed on the last fetched SHA1)
  • HEAD would point to the new commit checked-out.
  • no branch would be "checked-out": detached HEAD.

You would need to open that checked-out commit done on top of FETCH_HEAD, and create a branch from there:

create a branch

(from the article "Git Lesson: Be mindful of a detached head")

In conclusion:

Each time you see a "checked-out tick" on the FETCH_HEAD reference, it is because it references the same SHA1 than the ref currently checked out (either a commit, or a branch).
It is not because FETCH_HEAD itself is checked out: it you do a new commit on top of it, it won't be checked out anymore.

Community
  • 1
  • 1
VonC
  • 1,262,500
  • 529
  • 4,410
  • 5,250
  • You say: "As it doesn't reference a branch, it sin"t checked out..." Well it certainly shows as being checked out right after cloning and right after merging. (I added an image to the original question.) Sounds like this might be a Egit issue. – mike Aug 07 '13 at 22:56
  • @mike you need to see the situation from the perspective of "what happens when I make a *new* commit on top of that "checked-out" `FETCH_HEAD`?": I have updated my answer to illustrate that. – VonC Aug 08 '13 at 05:30
  • @mike I have added a small conclusion which summarizes why `FETCH_HEAD` *appears* checked out, but isn't really. – VonC Aug 08 '13 at 08:27