origin/branchname and tracking branch pointing to different commits?

origin/branchname and tracking branch pointing to different commits?

[Eugene Sajine]

Hi,

Could you, please, help me to understand how it is  possible to have a
tracking branch named qa which tracks origin/qa both pointing to
different commits after git pull origin qa?

I.e. I currently see this picture in my repository when

$ git co qa
$git log

gives me qa branch history advanced by 4 commits comparing to origin/qa

while

$git pull origin qa

says it is already up to date

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.

Thanks,
Eugene

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

[Matthieu Moy]

Eugene Sajine <euguess@gmail.com> writes:

> gives me qa branch history advanced by 4 commits comparing to
> origin/qa

This means you have local commits which are not in the remote branch.

> $git pull origin qa

If you want to send your local commits, use "git push".

-- 
Matthieu Moy
http://www-verimag.imag.fr/~moy/

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

[Thomas Rast]

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

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

[Eugene Sajine]

On Thu, Jan 7, 2010 at 12:12 PM, Thomas Rast <trast@student.ethz.ch> wrote:
> 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?

Thanks,
Eugene

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

[Eugene Sajine]

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

let me correct my self a little bit:

$ git pull origin branchname

and

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

Thanks,
Eugene

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

[Junio C Hamano]

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.

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

[Eugene Sajine]

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

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

[Junio C Hamano]

Eugene Sajine <euguess@gmail.com> writes:

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

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

[Eugene Sajine]

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

Junio,

Yes, that's pretty much what we are doing. we are using "git fetch
origin" to update local remote branches (remote/branch) and then use
the information in there to inspect what are the incoming changes. I
was never teaching anybody to use "git fetch origin branch" So, we are
on the same page here with you.

The confusion though is that "git pull origin master" uses FETCH_HEAD
to store the information about remote master branch instead of
origin/master branch.
Therefore when people are using pull - they get confused why this
branch (origin/master) was not updated. Do you think that FETCH_HEAD
usage for pull still makes sense?

Thanks,
Eugene

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

[Jeff King]

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

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

[Eugene Sajine]

On Tue, Jun 8, 2010 at 2:30 PM, Jeff King <peff@peff.net> wrote:
> 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
>

Jeff, Junio

Could you, please, advise if there is any resolution on the patch?

Thanks a lot,
Eugene

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

[Junio C Hamano]

Eugene Sajine <euguess@gmail.com> writes:

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

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.

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

[Eugene Sajine]

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

Thank you, Junio, for the update.

Eugene

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

[Jeff King]

On Tue, Jun 29, 2010 at 12:27:09PM -0700, Junio C Hamano wrote:

> 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 am probably the best person to take another look at it (though I would
be fine if somebody else wants to volunteer).

Right now I am in the process of switching day jobs and doing an
inter-state move, so it will probably be a month before I have a lot of
git time.

-Peff