Passing -no-write-fetch-head from the command line tells Write the list of remote refs fetched in the FETCH_HEAD file directly under $GIT_DIR. Passing -write-fetch-head does not force ()(()) to write the file.įetch-options now includes in its man page: -write-fetch-head Note that under " -dry-run" mode, FETCH_HEAD is never written otherwise you'd see list of objects in the file that you do not actually have. The default is to write FETCH_HEAD, and the option is primarily meant to be used with the " -no-" prefix to override this default, because there is no matching fetch.writeFetchHEAD configuration variable to flip the default to off (in which case, the positive form may become necessary to defeat it).Teach " git fetch" ( man) a command line option " -write-fetch-head". you fetch and then merge origin/branchname separately), you can get away with having no FETCH_HEAD at all. you are merely mirroring) or if you always work from the remote-tracking refs (e.g. If you run fetch but record the result in remote-tracking branches, and either if you do nothing with the fetched refs (e.g. (Merged by Junio C Hamano - gitster - in commit b556050, ) fetch: optionally allow disabling FETCH_HEAD update See commit 887952b () by Junio C Hamano ( gitster). not always considering that, with Git 2.29 (Q4 2020), " git fetch" ( man) learned -no-write-fetch-head option to avoid writing the FETCH_HEAD file. (I am assuming that there is a nice clean tagged commit containing the whole of the bug fix on the server!)įETCH_HEAD is a short-lived ref, to keep track of what has just been fetched from the remote repository.Īctually. 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. You might want to use FETCH_HEAD at times though:- git fetch gitserver bugfix1234 (It is source:dest, see just in case you'd like to give it a different name!) to fetch release_1 and call it release_1 locally. 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 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. I then used FETCH_HEAD to create a local tag which matched the tag on the remote. 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. To complete the copy of the tagged chain of commits (release_1) from the remote repository to the local one. I had to type git tag release_1 FETCH_HEAD To my surprise, release_1 was then nowhere to be found on my local machine. Release_1 is a tag for a version of the software. Gitserver is the name of my machine that stores git repositories. I wanted a local copy of some software from a server and I did git fetch gitserver release_1 I have just discovered and used FETCH_HEAD.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |