From: Eugene Sajine Date: Tue, 08 Jun 2010 16:27:14 GMT Subject: Re: origin/branchname and tracking branch pointing to different commits? Message-ID: In-Reply-To: <7v7hrtzbau.fsf@alter.siamese.dyndns.org> On Thu, Jan 7, 2010 at 8:32 PM, Junio C Hamano wrote: > Eugene Sajine 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. > > I'm coming back to this topic as i see some confusion growing about such behavior. Every now and then users come across this problem and they expect pull to *really* behave as fetch and merge so it will cause the update of remote/branchname branch. And it is kind of difficult to justify why they have to do git fetch after pull... Can somebody, please, take a look? Thanks, Eugene