Re: `git fetch` not updating 'origin/HEAD' after branch rename

[Junio C Hamano <gitster@pobox.com>]

Sam Bostock <sam.bostock@shopify.com> 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.