Sam Bostock <sam.bostock@xxxxxxxxxxx> writes: > Hopefully I followed the instructions on https://git-scm.com/community > correctly to report this bug. > > Long story short, it seems to me that `git fetch` should update > "refs/remotes/origin/HEAD" when the upstream HEAD changes, but it > doesn't. See my filled out bug report below. That is working as intended. Since its inception, refs/remotes/origin/HEAD has been designed to mean "the branch, which the owner of the repository considers the most interesting for his/her purpose to keep track in the 'origin' remote repository". It is perfectly OK to repoint origin/HEAD to point at another branch you are interested in after you make a clone. The origin/HEAD happens to be primed by noticing what the remote repository sets HEAD to point to their branch upon cloning, but that is purely for convenience (i.e. HEAD branch of a repository offered for cloning points at a branch the owner of the repository being cloned considers the primary branch in his/her repository, and that often coincides with the earlier definition of origin/HEAD for those who clone such a repository). It would be a bug to update it to something other than you set (either passively by keeping what "clone" gave you initially, or actively by updating it to point at another branch) upon "git fetch" from the remote. There was an idea floated to use the same mechanism used by "git clone" to prime origin/HEAD upon "git fetch" when origin/HEAD is missing, and I do not think there were many objections against the idea, so that may happen sometime in the future. It may also be possible to add "git fetch --reset-remote-tracking-HEAD" option to make "fetch" overwrite existing origin/HEAD but somebody has to propose such a change, argue for its benefit and get it accepted by the community. Thanks.
