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

> Eugene Sajine <euguess@gmail.com> writes:
>
>> $ git fetch origin branchname
>>
>> are both causing the output like this:
>>
>> From git://....
>> * branch      branchname    -> FETCH_HEAD
>> ...
>>
>> but "git fetch" says:
>>
>> From git://....
>> * branch      branchname    -> origin/branchname
>>
>> Is this inconsistent behavior necessary by design?
>
> 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.
>
>