{"thread":{"id":"22118","subject":"origin/branchname and tracking branch pointing to different commits?","startedAt":"2010-01-07T17:03:45Z","lastAt":"2010-06-29T22:39:19Z","messageCount":14,"participants":["Eugene Sajine","Matthieu Moy","Thomas Rast","Junio C Hamano","Jeff King"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"131010","messageId":"76c5b8581001070903i3810f63crd764d451f7454584@mail.gmail.com","threadId":"22118","inReplyTo":null,"subject":"origin/branchname and tracking branch pointing to different commits?","fromName":"Eugene Sajine","fromEmail":"euguess@gmail.com","sentAt":"2010-01-07T17:03:45Z","receivedAt":"2010-01-07T17:03:45Z","isPatch":false,"sender":{"key":"euguess@gmail.com","avatar":null},"body":"Hi,\n\nCould you, please, help me to understand how it is  possible to have a\ntracking branch named qa which tracks origin/qa both pointing to\ndifferent commits after git pull origin qa?\n\nI.e. I currently see this picture in my repository when\n\n$ git co qa\n$git log\n\ngives me qa branch history advanced by 4 commits comparing to origin/qa\n\nwhile\n\n$git pull origin qa\n\nsays it is already up to date\n\nSo, generally, speaking qa branch is fine and is in synch with the\nremote mainline, but the state of local origin/qa is not clear.\n\nThanks,\nEugene\n"},{"id":"131011","messageId":"vpqmy0plu91.fsf@bauges.imag.fr","threadId":"22118","inReplyTo":"76c5b8581001070903i3810f63crd764d451f7454584@mail.gmail.com","subject":"Re: origin/branchname and tracking branch pointing to different commits?","fromName":"Matthieu Moy","fromEmail":"matthieu.moy@grenoble-inp.fr","sentAt":"2010-01-07T17:06:34Z","receivedAt":"2010-01-07T17:06:34Z","isPatch":false,"sender":{"key":"matthieu.moy@grenoble-inp.fr","avatar":"https://gravatar.com/avatar/72c8a2705971a25dfaff23cece15130d405685845d911aedd5667ace277f3fc5?d=mp&s=160"},"body":"Eugene Sajine writes:\n\n> gives me qa branch history advanced by 4 commits comparing to\n> origin/qa\n\nThis means you have local commits which are not in the remote branch.\n\n> $git pull origin qa\n\nIf you want to send your local commits, use \"git push\".\n\n-- \nMatthieu Moy\nhttp://www-verimag.imag.fr/~moy/\n"},{"id":"131016","messageId":"201001071813.01187.trast@student.ethz.ch","threadId":"22118","inReplyTo":"76c5b8581001070903i3810f63crd764d451f7454584@mail.gmail.com","subject":"Re: origin/branchname and tracking branch pointing to different commits?","fromName":"Thomas Rast","fromEmail":"trast@student.ethz.ch","sentAt":"2010-01-07T17:12:59Z","receivedAt":"2010-01-07T17:12:59Z","isPatch":false,"sender":{"key":"tr@thomasrast.ch","avatar":"https://avatars.githubusercontent.com/u/153510?v=4"},"body":"Eugene Sajine wrote:\n> $git pull origin qa\n[...]\n> So, generally, speaking qa branch is fine and is in synch with the\n> remote mainline, but the state of local origin/qa is not clear.\n\n'git pull $remote $branch' does not update the $remote/$branch\nremote-tracking branch; it stores in FETCH_HEAD and merges straight\nfrom there.\n\n-- \nThomas Rast\ntrast@{inf,student}.ethz.ch\n"},{"id":"131017","messageId":"76c5b8581001070925g21ac3136x2928f12dc43437e5@mail.gmail.com","threadId":"22118","inReplyTo":"201001071813.01187.trast@student.ethz.ch","subject":"Re: origin/branchname and tracking branch pointing to different commits?","fromName":"Eugene Sajine","fromEmail":"euguess@gmail.com","sentAt":"2010-01-07T17:25:04Z","receivedAt":"2010-01-07T17:25:04Z","isPatch":false,"sender":{"key":"euguess@gmail.com","avatar":null},"body":"On Thu, Jan 7, 2010 at 12:12 PM, Thomas Rast wrote:\n> Eugene Sajine wrote:\n>> $git pull origin qa\n> [...]\n>> So, generally, speaking qa branch is fine and is in synch with the\n>> remote mainline, but the state of local origin/qa is not clear.\n>\n> 'git pull $remote $branch' does not update the $remote/$branch\n> remote-tracking branch; it stores in FETCH_HEAD and merges straight\n> from there.\n>\n> --\n> Thomas Rast\n> trast@{inf,student}.ethz.ch\n>\n\nYep. That's what i though it is. I.e. origin/branchname will point\nalways to the last pushed commit only. Isn't it a bit strange that git\nfetch doesn't update origin/qa?\n\nProbably the problem is that whenever I'm pulling or pushing to remote\nrepo i expect the last updated state of particular remote branch to be\nreflected in origin/branchname, but IMHO it is correct expectation...\n\nWhat do you think?\n\nThanks,\nEugene\n"},{"id":"131053","messageId":"76c5b8581001071550g31e9f5a3n15ebdb10a806ab2e@mail.gmail.com","threadId":"22118","inReplyTo":"76c5b8581001070925g21ac3136x2928f12dc43437e5@mail.gmail.com","subject":"Re: origin/branchname and tracking branch pointing to different commits?","fromName":"Eugene Sajine","fromEmail":"euguess@gmail.com","sentAt":"2010-01-07T23:50:10Z","receivedAt":"2010-01-07T23:50:10Z","isPatch":false,"sender":{"key":"euguess@gmail.com","avatar":null},"body":">\n> Yep. That's what i though it is. I.e. origin/branchname will point\n> always to the last pushed commit only. Isn't it a bit strange that git\n> fetch doesn't update origin/qa?\n>\n> Probably the problem is that whenever I'm pulling or pushing to remote\n> repo i expect the last updated state of particular remote branch to be\n> reflected in origin/branchname, but IMHO it is correct expectation...\n>\n> What do you think?\n\nlet me correct my self a little bit:\n\n$ git pull origin branchname\n\nand\n\n$git fetch origin branchname\n\nare both causing the output like this:\n\n>From git://....\n* branch branchname -> FETCH_HEAD\n...\n\nbut \"git fetch\" says:\n\n>From git://....\n* branch branchname -> origin/branchname\n\nIs this inconsistent behavior necessary by design?\n\nThanks,\nEugene\n"},{"id":"131054","messageId":"7v7hrtzbau.fsf@alter.siamese.dyndns.org","threadId":"22118","inReplyTo":"76c5b8581001071550g31e9f5a3n15ebdb10a806ab2e@mail.gmail.com","subject":"Re: origin/branchname and tracking branch pointing to different commits?","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2010-01-08T00:32:09Z","receivedAt":"2010-01-08T00:32:09Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Eugene Sajine writes:\n\n> $ git fetch origin branchname\n>\n> are both causing the output like this:\n>\n> From git://....\n> * branch branchname -> FETCH_HEAD\n> ...\n>\n> but \"git fetch\" says:\n>\n> From git://....\n> * branch branchname -> origin/branchname\n>\n> Is this inconsistent behavior necessary by design?\n\nIt is by design; it is debatable if it still makes sense, though.\n\nBack when \"git fetch\" was invented, there weren't separate refs/remotes/\nhierarchy, the distinction between what's local and what's remote were\nonly in user's head. It made quite a lot of sense to have an explicit way\nto prevent \"fetch\" from overwriting all the branches that track branches\nfrom remote. Suppose you have already spend considerable time inspecting\n'origin/branch' and decided that has a suitable commit to build your\nchanges on, but you needed to work on something else first. If \"git fetch\norigin other\", an explicit request about \"other\" branch, updated an\nunrelated \"origin/branch\" at the same time, you couldn't recover from it\nby using \"origin/branch@{1}\", because reflog is a fairly recent invention.\n\nAn explicit \"git fetch origin other\" is a way to prevent such an update\nfrom happening. It does not update anything in refs/ hierarchy, even when\nyou have configured to make an implicit 'git fetch $there' make a copy of\n$this_ref somewhere in your refs/remotes/$there/ hierarchy in .git/config\n(back then the same information came from .git/remotes).\n\nBecause we have reflogs on by default, and refs/remotes/ is a separate\nhierarchy that is read-only from the local user's point of view, I think\nthe 'explicit fetch' syntax, as a way to stop tracking branches from\ngetting updated, ceased to be useful these days.\n"},{"id":"143252","messageId":"AANLkTinLVd483-ki6tVb545PgpOFeOLYLR_GiKM5xAl7@mail.gmail.com","threadId":"22118","inReplyTo":"7v7hrtzbau.fsf@alter.siamese.dyndns.org","subject":"Re: origin/branchname and tracking branch pointing to different commits?","fromName":"Eugene Sajine","fromEmail":"euguess@gmail.com","sentAt":"2010-06-08T16:27:14Z","receivedAt":"2010-06-08T16:27:14Z","isPatch":false,"sender":{"key":"euguess@gmail.com","avatar":null},"body":"On Thu, Jan 7, 2010 at 8:32 PM, Junio C Hamano wrote:\n> Eugene Sajine writes:\n>\n>> $ git fetch origin branchname\n>>\n>> are both causing the output like this:\n>>\n>> From git://....\n>> * branch      branchname    -> FETCH_HEAD\n>> ...\n>>\n>> but \"git fetch\" says:\n>>\n>> From git://....\n>> * branch      branchname    -> origin/branchname\n>>\n>> Is this inconsistent behavior necessary by design?\n>\n> It is by design; it is debatable if it still makes sense, though.\n>\n> Back when \"git fetch\" was invented, there weren't separate refs/remotes/\n> hierarchy, the distinction between what's local and what's remote were\n> only in user's head.  It made quite a lot of sense to have an explicit way\n> to prevent \"fetch\" from overwriting all the branches that track branches\n> from remote.  Suppose you have already spend considerable time inspecting\n> 'origin/branch' and decided that has a suitable commit to build your\n> changes on, but you needed to work on something else first.  If \"git fetch\n> origin other\", an explicit request about \"other\" branch, updated an\n> unrelated \"origin/branch\" at the same time, you couldn't recover from it\n> by using \"origin/branch@{1}\", because reflog is a fairly recent invention.\n>\n> An explicit \"git fetch origin other\" is a way to prevent such an update\n> from happening.  It does not update anything in refs/ hierarchy, even when\n> you have configured to make an implicit 'git fetch $there' make a copy of\n> $this_ref somewhere in your refs/remotes/$there/ hierarchy in .git/config\n> (back then the same information came from .git/remotes).\n>\n> Because we have reflogs on by default, and refs/remotes/ is a separate\n> hierarchy that is read-only from the local user's point of view, I think\n> the 'explicit fetch' syntax, as a way to stop tracking branches from\n> getting updated, ceased to be useful these days.\n>\n>\n\nI'm coming back to this topic as i see some confusion growing about\nsuch behavior. Every now and then users come across this problem and\nthey expect pull to *really* behave as fetch and merge so it will\ncause the update of remote/branchname branch. And it is kind of\ndifficult to justify why they have to do git fetch after pull...\n\nCan somebody, please, take a look?\n\nThanks,\nEugene\n"},{"id":"143255","messageId":"7vljaptp1j.fsf@alter.siamese.dyndns.org","threadId":"22118","inReplyTo":"AANLkTinLVd483-ki6tVb545PgpOFeOLYLR_GiKM5xAl7@mail.gmail.com","subject":"Re: origin/branchname and tracking branch pointing to different commits?","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2010-06-08T17:25:12Z","receivedAt":"2010-06-08T17:25:12Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Eugene Sajine writes:\n\n> On Thu, Jan 7, 2010 at 8:32 PM, Junio C Hamano wrote:\n>> Eugene Sajine writes:\n>>\n>>> $ git fetch origin branchname\n>>>\n>>> are both causing the output like this:\n>>>\n>>> From git://....\n>>> * branch      branchname    -> FETCH_HEAD\n>>> ...\n>>>\n>>> but \"git fetch\" says:\n>>>\n>>> From git://....\n>>> * branch      branchname    -> origin/branchname\n>>>\n>>> Is this inconsistent behavior necessary by design?\n>>\n>> It is by design...\n>\n> I'm coming back to this topic as i see some confusion growing about\n> such behavior. Every now and then users come across this problem and\n> they expect pull to *really* behave as fetch and merge so it will\n> cause the update of remote/branchname branch. And it is kind of\n> difficult to justify why they have to do git fetch after pull...\n>\n> Can somebody, please, take a look?\n\n\n\nIn your transcript, they can say \"git fetch\" (or \"git fetch origin\") and\nbranch is copied to origin/branch, so instead of doing:\n\n $ git fetch origin branchname\n $ git log FETCH_HEAD ;# or whatever inspection using FETCH_HEAD\n\nthey can do\n\n $ git fetch ;# or git fetch origin\n $ git log origin/branch ;# or whatever inspection using it\n\nIn short, teach them that they no longer have reason to learn or run \"git\nfetch origin branchname\".\n"},{"id":"143258","messageId":"AANLkTilfBqc3Qww-4MbAcxuqBIj0LdbW9R3QXjCiy_J4@mail.gmail.com","threadId":"22118","inReplyTo":"7vljaptp1j.fsf@alter.siamese.dyndns.org","subject":"Re: origin/branchname and tracking branch pointing to different commits?","fromName":"Eugene Sajine","fromEmail":"euguess@gmail.com","sentAt":"2010-06-08T17:50:51Z","receivedAt":"2010-06-08T17:50:51Z","isPatch":false,"sender":{"key":"euguess@gmail.com","avatar":null},"body":">\n> In your transcript, they can say \"git fetch\" (or \"git fetch origin\") and\n> branch is copied to origin/branch, so instead of doing:\n>\n>    $ git fetch origin branchname\n>    $ git log FETCH_HEAD ;# or whatever inspection using FETCH_HEAD\n>\n> they can do\n>\n>    $ git fetch ;# or git fetch origin\n>    $ git log origin/branch ;# or whatever inspection using it\n>\n> In short, teach them that they no longer have reason to learn or run \"git\n> fetch origin branchname\".\n>\n>\n\nJunio,\n\nYes, that's pretty much what we are doing. we are using \"git fetch\norigin\" to update local remote branches (remote/branch) and then use\nthe information in there to inspect what are the incoming changes. I\nwas never teaching anybody to use \"git fetch origin branch\" So, we are\non the same page here with you.\n\nThe confusion though is that \"git pull origin master\" uses FETCH_HEAD\nto store the information about remote master branch instead of\norigin/master branch.\nTherefore when people are using pull - they get confused why this\nbranch (origin/master) was not updated. Do you think that FETCH_HEAD\nusage for pull still makes sense?\n\nThanks,\nEugene\n"},{"id":"143262","messageId":"20100608183007.GA31293@coredump.intra.peff.net","threadId":"22118","inReplyTo":"AANLkTinLVd483-ki6tVb545PgpOFeOLYLR_GiKM5xAl7@mail.gmail.com","subject":"Re: origin/branchname and tracking branch pointing to different commits?","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2010-06-08T18:30:07Z","receivedAt":"2010-06-08T18:30:07Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Tue, Jun 08, 2010 at 12:27:14PM -0400, Eugene Sajine wrote:\n\n> I'm coming back to this topic as i see some confusion growing about\n> such behavior. Every now and then users come across this problem and\n> they expect pull to *really* behave as fetch and merge so it will\n> cause the update of remote/branchname branch. And it is kind of\n> difficult to justify why they have to do git fetch after pull...\n> \n> Can somebody, please, take a look?\n\nThis was discussed a while back:\n\n http://thread.gmane.org/gmane.comp.version-control.git/127163\n\nand I even posted a patch, but never followed up (I think mostly just\ndue to being busy).. There is some concern about unexpected ref updates,\nthough.\n\n-Peff\n"},{"id":"144399","messageId":"AANLkTik7bleuzqnMWMJoWljQ5zD0YbwBsFjZT5IzkV0q@mail.gmail.com","threadId":"22118","inReplyTo":"20100608183007.GA31293@coredump.intra.peff.net","subject":"Re: origin/branchname and tracking branch pointing to different commits?","fromName":"Eugene Sajine","fromEmail":"euguess@gmail.com","sentAt":"2010-06-28T17:43:22Z","receivedAt":"2010-06-28T17:43:22Z","isPatch":false,"sender":{"key":"euguess@gmail.com","avatar":null},"body":"On Tue, Jun 8, 2010 at 2:30 PM, Jeff King wrote:\n> On Tue, Jun 08, 2010 at 12:27:14PM -0400, Eugene Sajine wrote:\n>\n>> I'm coming back to this topic as i see some confusion growing about\n>> such behavior. Every now and then users come across this problem and\n>> they expect pull to *really* behave as fetch and merge so it will\n>> cause the update of remote/branchname branch. And it is kind of\n>> difficult to justify why they have to do git fetch after pull...\n>>\n>> Can somebody, please, take a look?\n>\n> This was discussed a while back:\n>\n>  http://thread.gmane.org/gmane.comp.version-control.git/127163\n>\n> and I even posted a patch, but never followed up (I think mostly just\n> due to being busy).. There is some concern about unexpected ref updates,\n> though.\n>\n> -Peff\n>\n\nJeff, Junio\n\nCould you, please, advise if there is any resolution on the patch?\n\nThanks a lot,\nEugene\n"},{"id":"144481","messageId":"7vocet8ws2.fsf@alter.siamese.dyndns.org","threadId":"22118","inReplyTo":"AANLkTik7bleuzqnMWMJoWljQ5zD0YbwBsFjZT5IzkV0q@mail.gmail.com","subject":"Re: origin/branchname and tracking branch pointing to different commits?","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2010-06-29T19:27:09Z","receivedAt":"2010-06-29T19:27:09Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Eugene Sajine writes:\n\n>> This was discussed a while back:\n>>\n>>  http://thread.gmane.org/gmane.comp.version-control.git/127163\n>>\n>> and I even posted a patch, but never followed up (I think mostly just\n>> due to being busy).. There is some concern about unexpected ref updates,\n>> though.\n>\n> Jeff, Junio\n>\n> Could you, please, advise if there is any resolution on the patch?\n\nI do agree with Jeff that what his patch tried to do back in August last\nyear was introducing backward compatibility and potentially breaking\nworkflows of existing users by updating refs in an unexpected ways.\n\nHowever, as I discussed in\n\n Subject: Re: origin/branchname and tracking branch pointing to different commits?\n Date: Thu, 07 Jan 2010 16:32:09 -0800\n Message-ID: <7v7hrtzbau.fsf@alter.siamese.dyndns.org>\n\nI have a slight suspicion that such an \"unexpected ref update\" is not a\nbig issue anymore. So in principle, I think it is fine to change the\nbehaviour of \"git fetch $there $these_explicit_refs\" to additionally\nfollow the configured remote tracking ref globbing patterns.\n\nBecause\n\n (1) the old patch was never tested in a production context (I don't think\n it even hit 'pu');\n\n (2) I offhand do not know how much the codebase changed in the area that\n would affect the assumptions the patch made back then; and\n\n (3) we will be in feature freeze for 1.7.2 anyway;\n\nI would rather not be the one who is forward-porting the patch myself\nif I can avoid it, however.\n\nI could queue a version of the patch (with updates if necessary) to 'pu',\nbut not much more than that right now.\n"},{"id":"144482","messageId":"AANLkTik61QMnAn7rEoIOHlCMAuWgpdXWvmGVLCTn9YD1@mail.gmail.com","threadId":"22118","inReplyTo":"7vocet8ws2.fsf@alter.siamese.dyndns.org","subject":"Re: origin/branchname and tracking branch pointing to different commits?","fromName":"Eugene Sajine","fromEmail":"euguess@gmail.com","sentAt":"2010-06-29T20:05:16Z","receivedAt":"2010-06-29T20:05:16Z","isPatch":false,"sender":{"key":"euguess@gmail.com","avatar":null},"body":">> Jeff, Junio\n>>\n>> Could you, please, advise if there is any resolution on the patch?\n>\n> I do agree with Jeff that what his patch tried to do back in August last\n> year was introducing backward compatibility and potentially breaking\n> workflows of existing users by updating refs in an unexpected ways.\n>\n> However, as I discussed in\n>\n>    Subject: Re: origin/branchname and tracking branch pointing to different  commits?\n>    Date: Thu, 07 Jan 2010 16:32:09 -0800\n>    Message-ID: <7v7hrtzbau.fsf@alter.siamese.dyndns.org>\n>\n> I have a slight suspicion that such an \"unexpected ref update\" is not a\n> big issue anymore.  So in principle, I think it is fine to change the\n> behaviour of \"git fetch $there $these_explicit_refs\" to additionally\n> follow the configured remote tracking ref globbing patterns.\n>\n> Because\n>\n>  (1) the old patch was never tested in a production context (I don't think\n>     it even hit 'pu');\n>\n>  (2) I offhand do not know how much the codebase changed in the area that\n>     would affect the assumptions the patch made back then; and\n>\n>  (3) we will be in feature freeze for 1.7.2 anyway;\n>\n> I would rather not be the one who is forward-porting the patch myself\n> if I can avoid it, however.\n>\n> I could queue a version of the patch (with updates if necessary) to 'pu',\n> but not much more than that right now.\n>\n>\n\nThank you, Junio, for the update.\n\nEugene\n"},{"id":"144486","messageId":"20100629223919.GB5668@sigill.intra.peff.net","threadId":"22118","inReplyTo":"7vocet8ws2.fsf@alter.siamese.dyndns.org","subject":"Re: origin/branchname and tracking branch pointing to different commits?","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2010-06-29T22:39:19Z","receivedAt":"2010-06-29T22:39:19Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Tue, Jun 29, 2010 at 12:27:09PM -0700, Junio C Hamano wrote:\n\n> I have a slight suspicion that such an \"unexpected ref update\" is not a\n> big issue anymore. So in principle, I think it is fine to change the\n> behaviour of \"git fetch $there $these_explicit_refs\" to additionally\n> follow the configured remote tracking ref globbing patterns.\n> \n> Because\n> \n> (1) the old patch was never tested in a production context (I don't think\n> it even hit 'pu');\n> \n> (2) I offhand do not know how much the codebase changed in the area that\n> would affect the assumptions the patch made back then; and\n> \n> (3) we will be in feature freeze for 1.7.2 anyway;\n> \n> I would rather not be the one who is forward-porting the patch myself\n> if I can avoid it, however.\n\nI am probably the best person to take another look at it (though I would\nbe fine if somebody else wants to volunteer).\n\nRight now I am in the process of switching day jobs and doing an\ninter-state move, so it will probably be a month before I have a lot of\ngit time.\n\n-Peff\n"}]}