Re: origin/branchname and tracking branch pointing to different commits?

Eugene Sajine <euguess@gmail.com> writes:

It is by design; it is debatable if it still makes sense, though.

Back when "git fetch" was invented, there weren't separate refs/remotes/ hierarchy, the distinction between what's local and what's remote were only in user's head. It made quite a lot of sense to have an explicit way to prevent "fetch" from overwriting all the branches that track branches from remote. Suppose you have already spend considerable time inspecting 'origin/branch' and decided that has a suitable commit to build your changes on, but you needed to work on something else first. If "git fetch origin other", an explicit request about "other" branch, updated an unrelated "origin/branch" at the same time, you couldn't recover from it by using "origin/branch@{1}", because reflog is a fairly recent invention.

An explicit "git fetch origin other" is a way to prevent such an update from happening. It does not update anything in refs/ hierarchy, even when you have configured to make an implicit 'git fetch $there' make a copy of $this_ref somewhere in your refs/remotes/$there/ hierarchy in .git/config (back then the same information came from .git/remotes).

Because we have reflogs on by default, and refs/remotes/ is a separate hierarchy that is read-only from the local user's point of view, I think the 'explicit fetch' syntax, as a way to stop tracking branches from getting updated, ceased to be useful these days.