I have just discovered and used FETCH_HEAD
. I wanted a local copy of some software from a server and I did
git fetch gitserver release_1
gitserver
is the name of my machine that stores git repositories.
release_1
is a tag for a version of the software. To my surprise, release_1
was then nowhere to be found on my local machine. I had to type
git tag release_1 FETCH_HEAD
to complete the copy of the tagged chain of commits (release_1) from the remote repository to the local one. Fetch had found the remote tag, copied the commit to my local machine, had not created a local tag, but had set FETCH_HEAD
to the value of the commit, so that I could find and use it. I then used FETCH_HEAD
to create a local tag which matched the tag on the remote. That is a practical illustration of what FETCH_HEAD
is and how it can be used, and might be useful to someone else wondering why git fetch doesn't do what you would naively expect.
In my opinion it is best avoided for that purpose and a better way to achieve what I was trying to do is
git fetch gitserver release_1:release_1
i.e. to fetch release_1 and call it release_1 locally. (It is source:dest, see https://git-scm.com/book/en/v2/Git-Internals-The-Refspec; just in case you'd like to give it a different name!)
You might want to use FETCH_HEAD
at times though:-
git fetch gitserver bugfix1234
git cherry-pick FETCH_HEAD
might be a nice way of using bug fix number 1234 from your Git server, and leaving Git's garbage collection to dispose of the copy from the server once the fix has been cherry-picked onto your current branch. (I am assuming that there is a nice clean tagged commit containing the whole of the bug fix on the server!)