Eugene Sajine <euguess@xxxxxxxxx> 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.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html