origin/branchname and tracking branch pointing to different commits?

> Eugene Sajine wrote:
>> $git pull origin qa
> [...]
>> So, generally, speaking qa branch is fine and is in synch with the
>> remote mainline, but the state of local origin/qa is not clear.
>
> 'git pull $remote $branch' does not update the $remote/$branch
> remote-tracking branch; it stores in FETCH_HEAD and merges straight
> from there.
>
> --
> Thomas Rast
> trast@{inf,student}.ethz.ch
>

>
> Yep. That's what i though it is. I.e. origin/branchname will point
> always to the last pushed commit only. Isn't it a bit strange that git
> fetch doesn't update origin/qa?
>
> Probably the problem is that whenever I'm pulling or pushing to remote
> repo i expect the last updated state of particular remote branch to be
> reflected in origin/branchname, but IMHO it is correct expectation...
>
> What do you think?

> $ 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?

> 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.
>
>

> On Thu, Jan 7, 2010 at 8:32 PM, Junio C Hamano <gitster@pobox.com> wrote:
>> 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...
>
> 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?

>
> In your transcript, they can say "git fetch" (or "git fetch origin") and
> branch is copied to origin/branch, so instead of doing:
>
>    $ git fetch origin branchname
>    $ git log FETCH_HEAD ;# or whatever inspection using FETCH_HEAD
>
> they can do
>
>    $ git fetch ;# or git fetch origin
>    $ git log origin/branch ;# or whatever inspection using it
>
> In short, teach them that they no longer have reason to learn or run "git
> fetch origin branchname".
>
>

> 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?

> On Tue, Jun 08, 2010 at 12:27:14PM -0400, Eugene Sajine wrote:
>
>> 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?
>
> This was discussed a while back:
>
>  http://thread.gmane.org/gmane.comp.version-control.git/127163
>
> and I even posted a patch, but never followed up (I think mostly just
> due to being busy).. There is some concern about unexpected ref updates,
> though.
>
> -Peff
>

>> This was discussed a while back:
>>
>>  http://thread.gmane.org/gmane.comp.version-control.git/127163
>>
>> and I even posted a patch, but never followed up (I think mostly just
>> due to being busy).. There is some concern about unexpected ref updates,
>> though.
>
> Jeff, Junio
>
> Could you, please, advise if there is any resolution on the patch?

>> Jeff, Junio
>>
>> Could you, please, advise if there is any resolution on the patch?
>
> I do agree with Jeff that what his patch tried to do back in August last
> year was introducing backward compatibility and potentially breaking
> workflows of existing users by updating refs in an unexpected ways.
>
> However, as I discussed in
>
>    Subject: Re: origin/branchname and tracking branch pointing to different  commits?
>    Date: Thu, 07 Jan 2010 16:32:09 -0800
>    Message-ID: <7v7hrtzbau.fsf@alter.siamese.dyndns.org>
>
> I have a slight suspicion that such an "unexpected ref update" is not a
> big issue anymore.  So in principle, I think it is fine to change the
> behaviour of "git fetch $there $these_explicit_refs" to additionally
> follow the configured remote tracking ref globbing patterns.
>
> Because
>
>  (1) the old patch was never tested in a production context (I don't think
>     it even hit 'pu');
>
>  (2) I offhand do not know how much the codebase changed in the area that
>     would affect the assumptions the patch made back then; and
>
>  (3) we will be in feature freeze for 1.7.2 anyway;
>
> I would rather not be the one who is forward-porting the patch myself
> if I can avoid it, however.
>
> I could queue a version of the patch (with updates if necessary) to 'pu',
> but not much more than that right now.
>
>

> I have a slight suspicion that such an "unexpected ref update" is not a
> big issue anymore.  So in principle, I think it is fine to change the
> behaviour of "git fetch $there $these_explicit_refs" to additionally
> follow the configured remote tracking ref globbing patterns.
> 
> Because
> 
>  (1) the old patch was never tested in a production context (I don't think
>      it even hit 'pu');
> 
>  (2) I offhand do not know how much the codebase changed in the area that
>      would affect the assumptions the patch made back then; and
> 
>  (3) we will be in feature freeze for 1.7.2 anyway;
> 
> I would rather not be the one who is forward-porting the patch myself
> if I can avoid it, however.