{"thread":{"id":"31245","subject":"Your branch and 'origin/master' have diverged","startedAt":"2012-08-13T19:58:40Z","lastAt":"2012-08-16T17:57:54Z","messageCount":20,"participants":["Hilco Wijbenga","Thomas Rast","PJ Weisberg","Junio C Hamano","Holger Hellmuth (IKS)","Jeff King"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"196930","messageId":"CAE1pOi1WTbMSK8dOus6pFCa2C9vGA8QNE3+8w0LFmGkvcfq5fg@mail.gmail.com","threadId":"31245","inReplyTo":null,"subject":"Your branch and 'origin/master' have diverged","fromName":"Hilco Wijbenga","fromEmail":"hilco.wijbenga@gmail.com","sentAt":"2012-08-13T19:58:40Z","receivedAt":"2012-08-13T19:58:40Z","isPatch":false,"sender":{"key":"hilco.wijbenga@gmail.com","avatar":null},"body":"Hi all,\n\nA colleague of mine (after a relatively long absence) noticed the\nfollowing when running \"git status\":\n\n# On branch master\n# Your branch and 'origin/master' have diverged,\n# and have 250 and 19 different commit(s) each, respectively.\n#\nnothing to commit (working directory clean)\n\nHe asked me what to do and I told him to do what has always worked for\nme in the past when something like this happened: gitk, \"reset master\nbranch to here\" (to a commit before the divergence and using --hard),\ngit pull origin master. Problem solved.\n\nWell, not this one. This one is persistent. :-) I am at a loss what to\ndo. \"master\" and \"origin/master\" do *not* point at the same commit.\nEven after the \"git reset --hard ...\" and \"git pull\". Running my\nsilver bullet solution gets us in the same situation every time.\n\nI checked his .git/config and it looks fine.\n\nAny ideas? What information should I provide that might make it\npossible for you to help me?\n\nCheers,\nHilco\n"},{"id":"196962","messageId":"87zk5x6fox.fsf@thomas.inf.ethz.ch","threadId":"31245","inReplyTo":"CAE1pOi1WTbMSK8dOus6pFCa2C9vGA8QNE3+8w0LFmGkvcfq5fg@mail.gmail.com","subject":"Re: Your branch and 'origin/master' have diverged","fromName":"Thomas Rast","fromEmail":"trast@student.ethz.ch","sentAt":"2012-08-14T08:27:58Z","receivedAt":"2012-08-14T08:27:58Z","isPatch":false,"sender":{"key":"tr@thomasrast.ch","avatar":"https://avatars.githubusercontent.com/u/153510?v=4"},"body":"Hilco Wijbenga writes:\n\n> # On branch master\n> # Your branch and 'origin/master' have diverged,\n> # and have 250 and 19 different commit(s) each, respectively.\n> #\n> nothing to commit (working directory clean)\n>\n> He asked me what to do and I told him to do what has always worked for\n> me in the past when something like this happened: gitk, \"reset master\n> branch to here\" (to a commit before the divergence and using --hard),\n> git pull origin master. Problem solved.\n\nThere are several layers of pitfalls and misunderstandings here.\n\n* Is your work origin/master..master (that is, anything in master but\n not origin/master) really so worthless as to make \"scrap it all!\" the\n normal course of resolution?\n\n Or perhaps the real reason for the divergence is that upstream rewrote\n its master (eeeek!), in which case you should get them acquainted with\n the clue bat... and probably rebase instead of merge.\n\n* pull = fetch + merge! Repeat this a few times until it sinks in.\n Then print it on A0 and stick it up in your office or something.\n\n For your case this means that the pull command is roughly equivalent\n to\n\n git fetch origin master\n git merge FETCH_HEAD\n\n The two-arg form of fetch does *not* update origin/master. Assuming\n you got the reset right, the merge will fast-forward to whatever\n origin's master points to -- but origin/master is still the old state!\n\n* Resetting to something that you think will fast-forward, only to then\n fast-forward it to the newest state, is silly. You can just reset to\n the newest state instead.\n\nTaking all of this together, I think you should stop using two-arg\npull[*] or fetch, and replace your error-prone recipe with simply\n\n git fetch\n git reset --hard origin/master\n\nAssuming, as before, that your local work is worthless. Is it?\nOtherwise it would be better to run something like\n\n git fetch\n git rebase origin/master\n\n\n[*] it's ok if you use it with an URL instead of a remote nickname\n\n-- \nThomas Rast\ntrast@{inf,student}.ethz.ch\n"},{"id":"196978","messageId":"CAJsNXTmUB-isPVHPcWupL-gAag--DzhdkazXj0Z+aEbv+_w7Rg@mail.gmail.com","threadId":"31245","inReplyTo":"CAE1pOi1WTbMSK8dOus6pFCa2C9vGA8QNE3+8w0LFmGkvcfq5fg@mail.gmail.com","subject":"Re: Your branch and 'origin/master' have diverged","fromName":"PJ Weisberg","fromEmail":"pj@irregularexpressions.net","sentAt":"2012-08-14T16:02:29Z","receivedAt":"2012-08-14T16:02:29Z","isPatch":false,"sender":{"key":"pj@irregularexpressions.net","avatar":"https://gravatar.com/avatar/aa2c1edcc61b536cc5c9f37fbce084e655446e2309f9818d43f13d47304a602b?d=mp&s=160"},"body":"On Mon, Aug 13, 2012 at 12:58 PM, Hilco Wijbenga\n wrote:\n> Hi all,\n>\n> A colleague of mine (after a relatively long absence) noticed the\n> following when running \"git status\":\n>\n> # On branch master\n> # Your branch and 'origin/master' have diverged,\n> # and have 250 and 19 different commit(s) each, respectively.\n> #\n> nothing to commit (working directory clean)\n>\n> He asked me what to do and I told him to do what has always worked for\n> me in the past when something like this happened: gitk, \"reset master\n> branch to here\" (to a commit before the divergence and using --hard),\n> git pull origin master. Problem solved.\n>\n> Well, not this one. This one is persistent. :-) I am at a loss what to\n> do. \"master\" and \"origin/master\" do *not* point at the same commit.\n> Even after the \"git reset --hard ...\" and \"git pull\". Running my\n> silver bullet solution gets us in the same situation every time.\n\nI assume that the commit you reset to wasn't actually before the\ndivergence, then. It sounds like what you're trying to do is just\nlong-hand for 'git reset --hard origin/master'. As mentioned before,\nthat *does* assume that you want to throw out everything you've\ncommitted locally. If that's *not* the case, try 'git rebase\norigin/master' or 'git pull --rebase'. And then go slap the person\nwho rewrote the history of origin/master.\n\n-PJ\n\nGehm's Corollary to Clark's Law: Any technology distinguishable from\nmagic is insufficiently advanced.\n"},{"id":"196983","messageId":"CAE1pOi1YFe9GB1L_==RTecEAipdTKj2-ixpwTnrmOgkkV8rkYw@mail.gmail.com","threadId":"31245","inReplyTo":"87zk5x6fox.fsf@thomas.inf.ethz.ch","subject":"Re: Your branch and 'origin/master' have diverged","fromName":"Hilco Wijbenga","fromEmail":"hilco.wijbenga@gmail.com","sentAt":"2012-08-14T17:04:03Z","receivedAt":"2012-08-14T17:04:03Z","isPatch":false,"sender":{"key":"hilco.wijbenga@gmail.com","avatar":null},"body":"On 14 August 2012 01:27, Thomas Rast wrote:\n> Hilco Wijbenga writes:\n>\n>> # On branch master\n>> # Your branch and 'origin/master' have diverged,\n>> # and have 250 and 19 different commit(s) each, respectively.\n>> #\n>> nothing to commit (working directory clean)\n>>\n>> He asked me what to do and I told him to do what has always worked for\n>> me in the past when something like this happened: gitk, \"reset master\n>> branch to here\" (to a commit before the divergence and using --hard),\n>> git pull origin master. Problem solved.\n>\n> There are several layers of pitfalls and misunderstandings here.\n>\n> * Is your work origin/master..master (that is, anything in master but\n> not origin/master) really so worthless as to make \"scrap it all!\" the\n> normal course of resolution?\n\nOf course, it's master. Nobody should be working on master directly.\n\n> Or perhaps the real reason for the divergence is that upstream rewrote\n> its master (eeeek!), in which case you should get them acquainted with\n> the clue bat... and probably rebase instead of merge.\n\nUpstream is fine. Nobody else is having any problems.\n\n> * pull = fetch + merge! Repeat this a few times until it sinks in.\n> Then print it on A0 and stick it up in your office or something.\n\nYes, I know.\n\n> For your case this means that the pull command is roughly equivalent\n> to\n>\n> git fetch origin master\n> git merge FETCH_HEAD\n>\n> The two-arg form of fetch does *not* update origin/master. Assuming\n> you got the reset right, the merge will fast-forward to whatever\n> origin's master points to -- but origin/master is still the old state!\n\nAh, now we're getting to something I did *not* know. :-) So FETCH_HEAD\n!= origin/master? I tried to find out more information about\nFETCH_HEAD but there doesn't seem to be much. I have seen \"FETCH_HEAD\"\nshow up in the terminal but always just ignored it as a Git\nimplementation detail. When/how does origin/master get set then? I\nalways assumed that was part of git fetch and then git merge would\nactually move master to origin/master.\n\n> * Resetting to something that you think will fast-forward, only to then\n> fast-forward it to the newest state, is silly. You can just reset to\n> the newest state instead.\n\n:-) Well, yeah, now that you point it out... :-)\n\nStill, just resetting ignores all the problems that led to the current\nsituation. Normally, when I reset and then FF I can be sure (if it\nworks) that things were not completely screwed up. At least, that has\nalways been my theory.\n\n> Taking all of this together, I think you should stop using two-arg\n> pull[*] or fetch, and replace your error-prone recipe with simply\n>\n> git fetch\n> git reset --hard origin/master\n>\n> Assuming, as before, that your local work is worthless. Is it?\n> Otherwise it would be better to run something like\n>\n> git fetch\n> git rebase origin/master\n>\n>\n> [*] it's ok if you use it with an URL instead of a remote nickname\n\nWhy would that be okay? What is the difference? Isn't the nickname\njust an alias for a URL?\n"},{"id":"196985","messageId":"CAE1pOi0UJYhFXYi_GQyK7EL+wifu1g-R34wgqHCcKpdhirytuw@mail.gmail.com","threadId":"31245","inReplyTo":"CAJsNXTmUB-isPVHPcWupL-gAag--DzhdkazXj0Z+aEbv+_w7Rg@mail.gmail.com","subject":"Re: Your branch and 'origin/master' have diverged","fromName":"Hilco Wijbenga","fromEmail":"hilco.wijbenga@gmail.com","sentAt":"2012-08-14T17:07:07Z","receivedAt":"2012-08-14T17:07:07Z","isPatch":false,"sender":{"key":"hilco.wijbenga@gmail.com","avatar":null},"body":"On 14 August 2012 09:02, PJ Weisberg wrote:\n> On Mon, Aug 13, 2012 at 12:58 PM, Hilco Wijbenga\n> wrote:\n>> Hi all,\n>>\n>> A colleague of mine (after a relatively long absence) noticed the\n>> following when running \"git status\":\n>>\n>> # On branch master\n>> # Your branch and 'origin/master' have diverged,\n>> # and have 250 and 19 different commit(s) each, respectively.\n>> #\n>> nothing to commit (working directory clean)\n>>\n>> He asked me what to do and I told him to do what has always worked for\n>> me in the past when something like this happened: gitk, \"reset master\n>> branch to here\" (to a commit before the divergence and using --hard),\n>> git pull origin master. Problem solved.\n>>\n>> Well, not this one. This one is persistent. :-) I am at a loss what to\n>> do. \"master\" and \"origin/master\" do *not* point at the same commit.\n>> Even after the \"git reset --hard ...\" and \"git pull\". Running my\n>> silver bullet solution gets us in the same situation every time.\n>\n> I assume that the commit you reset to wasn't actually before the\n> divergence, then.\n\nIt was according to gitk.\n\n> It sounds like what you're trying to do is just\n> long-hand for 'git reset --hard origin/master'. As mentioned before,\n> that *does* assume that you want to throw out everything you've\n> committed locally. If that's *not* the case, try 'git rebase\n> origin/master' or 'git pull --rebase'. And then go slap the person\n> who rewrote the history of origin/master.\n\nI'm not convinced anything is wrong with origin/master. This\nparticular colleague is the only one with a problem. And not for the\nfirst time. :-)\n"},{"id":"196987","messageId":"7v628lbdcw.fsf@alter.siamese.dyndns.org","threadId":"31245","inReplyTo":"CAE1pOi1YFe9GB1L_==RTecEAipdTKj2-ixpwTnrmOgkkV8rkYw@mail.gmail.com","subject":"Re: Your branch and 'origin/master' have diverged","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2012-08-14T17:19:27Z","receivedAt":"2012-08-14T17:19:27Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Hilco Wijbenga writes:\n\n> On 14 August 2012 01:27, Thomas Rast wrote:\n>> Hilco Wijbenga writes:\n>>\n>>> # On branch master\n>>> # Your branch and 'origin/master' have diverged,\n>>> # and have 250 and 19 different commit(s) each, respectively.\n>>> #\n>>> nothing to commit (working directory clean)\n>>>\n>>> He asked me what to do and I told him to do what has always worked for\n>>> me in the past when something like this happened: gitk, \"reset master\n>>> branch to here\" (to a commit before the divergence and using --hard),\n>>> git pull origin master. Problem solved.\n>>\n>> There are several layers of pitfalls and misunderstandings here.\n>>\n>> * Is your work origin/master..master (that is, anything in master but\n>> not origin/master) really so worthless as to make \"scrap it all!\" the\n>> normal course of resolution?\n>\n> Of course, it's master. Nobody should be working on master directly.\n\nWhat a strange thing to say. When will 'master' ever be updated\nthen and how?\n\nIf you mean 'master' as the integration branch for everybody to meet\nand make progress, it would be more common for everybody to be\nworking on his own topic branch until perfection of the topic,\nconcluded by merging the completed topic to master and pushing the\nmaster out to update it, no?\n\n>> * pull = fetch + merge! Repeat this a few times until it sinks in.\n>> Then print it on A0 and stick it up in your office or something.\n>\n> Yes, I know.\n>\n>> For your case this means that the pull command is roughly equivalent\n>> to\n>>\n>> git fetch origin master\n>> git merge FETCH_HEAD\n>>\n>> The two-arg form of fetch does *not* update origin/master. Assuming\n>> you got the reset right, the merge will fast-forward to whatever\n>> origin's master points to -- but origin/master is still the old state!\n>\n> Ah, now we're getting to something I did *not* know. :-) So FETCH_HEAD\n> != origin/master?\n>\n I tried to find out more information about\n> FETCH_HEAD but there doesn't seem to be much. I have seen \"FETCH_HEAD\"\n> show up in the terminal but always just ignored it as a Git\n> implementation detail. When/how does origin/master get set then? I\n> always assumed that was part of git fetch and then git merge would\n> actually move master to origin/master.\n\nIt could be \"git fetch --help\" is failing for you, but I am\nreasonably sure most if not all of the above are answered there;\nanother thing something you may not have known :-).\n\n>> Taking all of this together, I think you should stop using two-arg\n>> pull[*] or fetch, and replace your error-prone recipe with simply\n>>\n>> git fetch\n>> git reset --hard origin/master\n>>\n>> Assuming, as before, that your local work is worthless. Is it?\n>> Otherwise it would be better to run something like\n>>\n>> git fetch\n>> git rebase origin/master\n\nYeah, the latter makes sense, and I think it is a safer superset of\nthe former. If there is nothing of value on 'master', the rebase\nmight stop and give control back to the user, but the user can tell\nit to skip the cruft that came from the old 'master'.\n\n>> [*] it's ok if you use it with an URL instead of a remote nickname\n>\n> Why would that be okay? What is the difference? Isn't the nickname\n> just an alias for a URL?\n\nAs long as you tell what refspecs to use on the command line, the\nremote nickname behaves as \"just an alias for a URL\", so yes,\nbecause Thomas is discussing \"two-arg pull or fetch\", one arg being\neither nickname or URL and the other is an explicit refspec on the\ncommand line, it would be okay because there is no difference in\nthat case.\n"},{"id":"196990","messageId":"CAE1pOi2DZNkYYwkH1MFh0m708T=DEdJawZCQgvk1HTGrqjkz2w@mail.gmail.com","threadId":"31245","inReplyTo":"7v628lbdcw.fsf@alter.siamese.dyndns.org","subject":"Re: Your branch and 'origin/master' have diverged","fromName":"Hilco Wijbenga","fromEmail":"hilco.wijbenga@gmail.com","sentAt":"2012-08-14T18:32:54Z","receivedAt":"2012-08-14T18:32:54Z","isPatch":false,"sender":{"key":"hilco.wijbenga@gmail.com","avatar":null},"body":"On 14 August 2012 10:19, Junio C Hamano wrote:\n> Hilco Wijbenga writes:\n>\n>> On 14 August 2012 01:27, Thomas Rast wrote:\n>>> Hilco Wijbenga writes:\n>>>\n>>>> # On branch master\n>>>> # Your branch and 'origin/master' have diverged,\n>>>> # and have 250 and 19 different commit(s) each, respectively.\n>>>> #\n>>>> nothing to commit (working directory clean)\n>>>>\n>>>> He asked me what to do and I told him to do what has always worked for\n>>>> me in the past when something like this happened: gitk, \"reset master\n>>>> branch to here\" (to a commit before the divergence and using --hard),\n>>>> git pull origin master. Problem solved.\n>>>\n>>> There are several layers of pitfalls and misunderstandings here.\n>>>\n>>> * Is your work origin/master..master (that is, anything in master but\n>>> not origin/master) really so worthless as to make \"scrap it all!\" the\n>>> normal course of resolution?\n>>\n>> Of course, it's master. Nobody should be working on master directly.\n>\n> What a strange thing to say. When will 'master' ever be updated\n> then and how?\n\nWell, yes, just before pushing, you'd work on master for a few\nseconds. That doesn't really count. :-)\n\n> If you mean 'master' as the integration branch for everybody to meet\n> and make progress, it would be more common for everybody to be\n> working on his own topic branch until perfection of the topic,\n> concluded by merging the completed topic to master and pushing the\n> master out to update it, no?\n\nThat's what I should have said. I assumed way too much context. I\ndon't think all neurons are firing yet. :-(\n\n>>> * pull = fetch + merge! Repeat this a few times until it sinks in.\n>>> Then print it on A0 and stick it up in your office or something.\n>>\n>> Yes, I know.\n>>\n>>> For your case this means that the pull command is roughly equivalent\n>>> to\n>>>\n>>> git fetch origin master\n>>> git merge FETCH_HEAD\n>>>\n>>> The two-arg form of fetch does *not* update origin/master. Assuming\n>>> you got the reset right, the merge will fast-forward to whatever\n>>> origin's master points to -- but origin/master is still the old state!\n>>\n>> Ah, now we're getting to something I did *not* know. :-) So FETCH_HEAD\n>> != origin/master?\n>>\n> I tried to find out more information about\n>> FETCH_HEAD but there doesn't seem to be much. I have seen \"FETCH_HEAD\"\n>> show up in the terminal but always just ignored it as a Git\n>> implementation detail. When/how does origin/master get set then? I\n>> always assumed that was part of git fetch and then git merge would\n>> actually move master to origin/master.\n>\n> It could be \"git fetch --help\" is failing for you, but I am\n> reasonably sure most if not all of the above are answered there;\n> another thing something you may not have known :-).\n\nI was actually looking at \"git help merge\" since \"git help fetch\"\nwould be a far too logical place for FETCH_HEAD information. ;-) As I\nsaid, not all neurons seem to be firing yet.\n\nApparently, my understanding is mostly correct, though. FETCH_HEAD is\nindeed origin/master (I mean the SHA1 in master's HEAD on origin) and\nthe \"git merge\" part of \"git pull\" eventually sets \"my\" origin/master.\n\n>>> Taking all of this together, I think you should stop using two-arg\n>>> pull[*] or fetch, and replace your error-prone recipe with simply\n>>>\n>>> git fetch\n>>> git reset --hard origin/master\n>>>\n>>> Assuming, as before, that your local work is worthless. Is it?\n>>> Otherwise it would be better to run something like\n>>>\n>>> git fetch\n>>> git rebase origin/master\n>\n> Yeah, the latter makes sense, and I think it is a safer superset of\n> the former. If there is nothing of value on 'master', the rebase\n> might stop and give control back to the user, but the user can tell\n> it to skip the cruft that came from the old 'master'.\n>\n>>> [*] it's ok if you use it with an URL instead of a remote nickname\n>>\n>> Why would that be okay? What is the difference? Isn't the nickname\n>> just an alias for a URL?\n>\n> As long as you tell what refspecs to use on the command line, the\n> remote nickname behaves as \"just an alias for a URL\", so yes,\n> because Thomas is discussing \"two-arg pull or fetch\", one arg being\n> either nickname or URL and the other is an explicit refspec on the\n> command line, it would be okay because there is no difference in\n> that case.\n\nI suppose I'm not entirely clear on how this two step process is\n\"safer\". Doing \"git fetch\" would seem to be harmless, right? So the\nproblem is with \"git merge\" but master should always be \"behind\"\norigin/master so that \"git merge\" should just FF to origin/master\nwhich *should* be completely safe. Does that make sense? Especially\ngiven our use of master as an integration branch?\n\n[Given the trouble I have with getting people to use Git properly, I\nprefer things as simple as possible. :-) ]\n"},{"id":"196992","messageId":"7vlihh9ulo.fsf@alter.siamese.dyndns.org","threadId":"31245","inReplyTo":"CAE1pOi2DZNkYYwkH1MFh0m708T=DEdJawZCQgvk1HTGrqjkz2w@mail.gmail.com","subject":"Re: Your branch and 'origin/master' have diverged","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2012-08-14T18:49:55Z","receivedAt":"2012-08-14T18:49:55Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Hilco Wijbenga writes:\n\n> I suppose I'm not entirely clear on how this two step process is\n> \"safer\". Doing \"git fetch\" would seem to be harmless, right? So the\n> problem is with \"git merge\" but master should always be \"behind\"\n> origin/master so that \"git merge\" should just FF to origin/master\n> which *should* be completely safe. Does that make sense? Especially\n> given our use of master as an integration branch?\n>\n> [Given the trouble I have with getting people to use Git properly, I\n> prefer things as simple as possible. :-) ]\n\nBetween the two procedures Thomas gave you, \"fetch & rebase\" is\nsafer than \"fetch & reset --hard\", exactly because it does not have\nto rely on the validity of your \"which should always be behind\"\nclaim.\n\nIf it is behind, there won't be any difference, but if it is *not*,\nthe user will notice and won't lose his work on 'master' (which you\nmay argue that he shouldn't have done). \"rebase\" will notice it.\n\nThe key for a procedure to be safe is not having to rely on the\nclaim of users such as \"my history *should* always and already be\nbehind\", and not silently lose information when these *should*s are\nviolated for whatever reason. After all, if all these *should*s\nwere true, the user wouldn't have been having problems in the first\nplace and posting to the list asking for help in the first place ;-)\n"},{"id":"197012","messageId":"87lihh8c7s.fsf@thomas.inf.ethz.ch","threadId":"31245","inReplyTo":"CAE1pOi2DZNkYYwkH1MFh0m708T=DEdJawZCQgvk1HTGrqjkz2w@mail.gmail.com","subject":"Re: Your branch and 'origin/master' have diverged","fromName":"Thomas Rast","fromEmail":"trast@student.ethz.ch","sentAt":"2012-08-14T20:12:23Z","receivedAt":"2012-08-14T20:12:23Z","isPatch":false,"sender":{"key":"tr@thomasrast.ch","avatar":"https://avatars.githubusercontent.com/u/153510?v=4"},"body":"Hilco Wijbenga writes:\n\n> On 14 August 2012 10:19, Junio C Hamano wrote:\n>> Hilco Wijbenga writes:\n>>\n>>> On 14 August 2012 01:27, Thomas Rast wrote:\n>>>> [git pull with two args] it's ok if you use it with an URL instead\n>>>> of a remote nickname\n>>>\n>>> Why would that be okay? What is the difference? Isn't the nickname\n>>> just an alias for a URL?\n>>\n>> As long as you tell what refspecs to use on the command line, the\n>> remote nickname behaves as \"just an alias for a URL\", so yes,\n>> because Thomas is discussing \"two-arg pull or fetch\", one arg being\n>> either nickname or URL and the other is an explicit refspec on the\n>> command line, it would be okay because there is no difference in\n>> that case.\n>\n> I suppose I'm not entirely clear on how this two step process is\n> \"safer\". Doing \"git fetch\" would seem to be harmless, right? So the\n> problem is with \"git merge\" but master should always be \"behind\"\n> origin/master so that \"git merge\" should just FF to origin/master\n> which *should* be completely safe. Does that make sense? Especially\n> given our use of master as an integration branch?\n>\n> [Given the trouble I have with getting people to use Git properly, I\n> prefer things as simple as possible. :-) ]\n\nI meant something else than Junio hinted at. Saying\n\n git fetch origin master\n # or by extension\n git pull origin master\n\ndoes not update the origin/* namespace, not even origin/master. All\nfetching happens only into FETCH_HEAD. This leads to confusion such as\nyours because origin/master and thus the upstream tracking displays will\nnot know about the change.\n\nIf you use it with an URL, such as one that might be sent with a pull\nrequest:\n\n} The following changes since commit 62bc83349d52be49b037d2c800a7f4064cfbc5b5:\n} \n} The sixth batch of topics graduated to 'master' (2012-04-27 14:12:56 -0700)\n} \n} are available in the git repository at:\n} \n} https://github.com/git-l10n/git-po/ master\n\n(I picked a random pull request from the l10n coordinator, Jiang Xin)\nyou would say\n\n git pull https://github.com/git-l10n/git-po/ master\n\nand you would not have a reasonable expectation of git updating your\nremotes/*, even if you had a remote 'l10n' that points at that exact\nURL. So you would not be confused if you pulled from there, but\nl10n/master didn't move.\n\n\nIn some sense this is a really bad case of wrong UI design, because we\n(this happens on #git a lot) have to teach users not to use the command\nso they won't trip over this problem. It would be better to fix the\nreal issue instead. IIRC it was even on the 1.8.0 wishlist...\n\n-- \nThomas Rast\ntrast@{inf,student}.ethz.ch\n"},{"id":"197020","messageId":"7vr4r98ah5.fsf@alter.siamese.dyndns.org","threadId":"31245","inReplyTo":"87lihh8c7s.fsf@thomas.inf.ethz.ch","subject":"Re: Your branch and 'origin/master' have diverged","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2012-08-14T20:49:58Z","receivedAt":"2012-08-14T20:49:58Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Thomas Rast writes:\n\n> In some sense this is a really bad case of wrong UI design, because we\n> (this happens on #git a lot) have to teach users not to use the command\n> so they won't trip over this problem. It would be better to fix the\n> real issue instead. IIRC it was even on the 1.8.0 wishlist...\n\nIs it?\n\nThere already is a way to ask it to update the single tracking\nbranch while fetching; \"git fetch origin master\" that\nunconditionally updates refs/remotes/origin/master without a way to\ntell it not to do so will be a grave usability regression.\n"},{"id":"197025","messageId":"CAE1pOi3a9ZMFfJ2qjkaZ_O-DuQa3xkKtsMU5GYYUuiwcRoFjbg@mail.gmail.com","threadId":"31245","inReplyTo":"87lihh8c7s.fsf@thomas.inf.ethz.ch","subject":"Re: Your branch and 'origin/master' have diverged","fromName":"Hilco Wijbenga","fromEmail":"hilco.wijbenga@gmail.com","sentAt":"2012-08-14T22:15:54Z","receivedAt":"2012-08-14T22:15:54Z","isPatch":false,"sender":{"key":"hilco.wijbenga@gmail.com","avatar":null},"body":"On 14 August 2012 13:12, Thomas Rast wrote:\n> Hilco Wijbenga writes:\n>\n>> On 14 August 2012 10:19, Junio C Hamano wrote:\n>>> Hilco Wijbenga writes:\n>>>\n>>>> On 14 August 2012 01:27, Thomas Rast wrote:\n>>>>> [git pull with two args] it's ok if you use it with an URL instead\n>>>>> of a remote nickname\n>>>>\n>>>> Why would that be okay? What is the difference? Isn't the nickname\n>>>> just an alias for a URL?\n>>>\n>>> As long as you tell what refspecs to use on the command line, the\n>>> remote nickname behaves as \"just an alias for a URL\", so yes,\n>>> because Thomas is discussing \"two-arg pull or fetch\", one arg being\n>>> either nickname or URL and the other is an explicit refspec on the\n>>> command line, it would be okay because there is no difference in\n>>> that case.\n>>\n>> I suppose I'm not entirely clear on how this two step process is\n>> \"safer\". Doing \"git fetch\" would seem to be harmless, right? So the\n>> problem is with \"git merge\" but master should always be \"behind\"\n>> origin/master so that \"git merge\" should just FF to origin/master\n>> which *should* be completely safe. Does that make sense? Especially\n>> given our use of master as an integration branch?\n>>\n>> [Given the trouble I have with getting people to use Git properly, I\n>> prefer things as simple as possible. :-) ]\n>\n> I meant something else than Junio hinted at. Saying\n>\n> git fetch origin master\n> # or by extension\n> git pull origin master\n>\n> does not update the origin/* namespace, not even origin/master. All\n> fetching happens only into FETCH_HEAD. This leads to confusion such as\n> yours because origin/master and thus the upstream tracking displays will\n> not know about the change.\n\nI'll say. Now I'm really confused.\n\nIf what you say is true then what is updating origin/master? I've been\nusing \"git pull\" daily for over a year and origin/master is definitely\ngetting updated (at least according to gitk).\n\nMmm, just to make sure we are all talking about the same\norigin/master: I mean my local reference to the SHA1 of the commit\nthat is master's HEAD on origin. After I have run \"git pull\", *my*\nmaster and *my* origin/master point to the same commit. Or I'm\n*really* confused. Or I've confused you by using incorrect\nterminology. :-) Or by using the right terminology incorrectly. ;-)\n"},{"id":"197028","messageId":"7v628l85l4.fsf@alter.siamese.dyndns.org","threadId":"31245","inReplyTo":"CAE1pOi3a9ZMFfJ2qjkaZ_O-DuQa3xkKtsMU5GYYUuiwcRoFjbg@mail.gmail.com","subject":"Re: Your branch and 'origin/master' have diverged","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2012-08-14T22:35:35Z","receivedAt":"2012-08-14T22:35:35Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Hilco Wijbenga writes:\n\n>> I meant something else than Junio hinted at. Saying\n>>\n>> git fetch origin master\n>> # or by extension\n>> git pull origin master\n>>\n>> does not update the origin/* namespace, not even origin/master. All\n>> fetching happens only into FETCH_HEAD. This leads to confusion such as\n>> yours because origin/master and thus the upstream tracking displays will\n>> not know about the change.\n>\n> I'll say. Now I'm really confused.\n>\n> If what you say is true then what is updating origin/master? I've been\n> using \"git pull\" daily for over a year and origin/master is definitely\n> getting updated (at least according to gitk).\n\nNow it is really the time for you to go back to \"git fetch --help\"\nand read up on refspecs.\n\nWith\n\n $ git fetch origin\n\nyou are not telling \"fetch\" what to fetch, so it goes to your .git/config\nand finds remote.origin section to find what refspec to use. They\nwould say something like\n\n\t[remote \"origin\"]\n \turl = ...\n fetch = refs/heads/*:refs/remotes/origin/*\n\nmeaning (see the manual) \"fetch all the branches there, store them\nwith the corresponding name under refs/remotes/origin\".\n\nWith\n\n $ git fetch origin master\n\nyou are overiding the refspec in .git/config and explicitly saying\n\"I want to fetch the master branch, but do not want to update\nanything with it\". It is a short-hand for\n\n $ git fetch origin refs/heads/master\n\nwhich in turn is a short-hand for\n\n $ git fetch origin refs/heads/master:\n\nIf you wanted to update the tracking ref, you would use a refspec\nwith non-empty strings on the both sides of colon, i.e.\n\n $ git fetch origin master:refs/remotes/origin/master\n"},{"id":"197033","messageId":"87sjbo63pl.fsf@thomas.inf.ethz.ch","threadId":"31245","inReplyTo":"7vr4r98ah5.fsf@alter.siamese.dyndns.org","subject":"Re: Your branch and 'origin/master' have diverged","fromName":"Thomas Rast","fromEmail":"trast@student.ethz.ch","sentAt":"2012-08-15T06:59:02Z","receivedAt":"2012-08-15T06:59:02Z","isPatch":false,"sender":{"key":"tr@thomasrast.ch","avatar":"https://avatars.githubusercontent.com/u/153510?v=4"},"body":"Junio C Hamano writes:\n\n> Thomas Rast writes:\n>\n>> In some sense this is a really bad case of wrong UI design, because we\n>> (this happens on #git a lot) have to teach users not to use the command\n>> so they won't trip over this problem. It would be better to fix the\n>> real issue instead. IIRC it was even on the 1.8.0 wishlist...\n>\n> Is it?\n>\n> There already is a way to ask it to update the single tracking\n> branch while fetching; \"git fetch origin master\" that\n> unconditionally updates refs/remotes/origin/master without a way to\n> tell it not to do so will be a grave usability regression.\n\nGrave? Do you have any data/use-cases to back that up with?\n\nI have never had a need for a fetch that doesn't update the remote\nnamespace, nor heard anyone on IRC who has. OTOH, I do have anecdotal\nevidence in support of \"the current state is confusing\": this thread, or\nthe fact that Jan's IRC bot grew bot-quotes !fetch4/!pull4 that people\nuse to warn users of 'git pull origin master' (it's apparently very\ncommon).\n\n\nThe 1.8.0 thread is here, and Peff even said he had a patch he uses in\nhis tree:\n\nhttp://thread.gmane.org/gmane.comp.version-control.git/165720/focus=165758\n\nThere's even a newer thread suggesting the same:\n\nhttp://thread.gmane.org/gmane.comp.version-control.git/192252\n\n-- \nThomas Rast\ntrast@{inf,student}.ethz.ch\n"},{"id":"197045","messageId":"7vfw7o6p1g.fsf@alter.siamese.dyndns.org","threadId":"31245","inReplyTo":"87sjbo63pl.fsf@thomas.inf.ethz.ch","subject":"Re: Your branch and 'origin/master' have diverged","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2012-08-15T17:30:35Z","receivedAt":"2012-08-15T17:30:35Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Thomas Rast writes:\n\n> Junio C Hamano writes:\n>\n>> Thomas Rast writes:\n>>\n>>> In some sense this is a really bad case of wrong UI design, because we\n>>> (this happens on #git a lot) have to teach users not to use the command\n>>> so they won't trip over this problem. It would be better to fix the\n>>> real issue instead. IIRC it was even on the 1.8.0 wishlist...\n>>\n>> Is it?\n>>\n>> There already is a way to ask it to update the single tracking\n>> branch while fetching; \"git fetch origin master\" that\n>> unconditionally updates refs/remotes/origin/master without a way to\n>> tell it not to do so will be a grave usability regression.\n>\n> Grave? Do you have any data/use-cases to back that up with?\n\nWhen I get a pull request from say Eric, I would:\n\n\tgit fetch git-svn master\n git show-branch remotes/git-svn/master FETCH_HEAD\n\nto see what happened since the last pull request on the other side.\nHe may have rebased (which is not necessarily a crime), or I may see\nmore commits in the output than what he lists in the request message\n(which may indicate I may have missed an earlier pull request from\nhim).\n\nSuch a sanity check will stop working if the first \"fetch\" updated\nmy remotes/git-svn/master. I would have to enable reflog for\ntracking branch and do something like this:\n\n\tgit show-branch remotes/git-svn/master@{1} remotes/git-svn/master\n\nSo I was correct in saying that without an easy escape hatch, such a\nchange would be a regression.\n\nBut I think I (and others) could just train fingers to do\n\n\tgit fetch git-svn master:\n\nas a workaround.\n\nUpdating Documentation/pull-fetch-param.txt would be a bear, though.\nThe documentation is stale in that it was written in the days back\nwhen .git/remotes/ was the primary way to configure remotes, and was\nnot adjusted to use the termilology used in the [remote \"where\"]\nsection of the .git/config file (notice a mention of \"'Pull: '\nlines\" there), so it needs cosmetic adjustment anyway, but the\nsemantics it spells is still up to date. The current rule is very\nsimple and understandable. You either say from the command line\nexactly what should happen (refspec without colon is the same as the\nrefspec with colon at the end, meaning \"do not track\"; if you want\nto track, you write what to update with the fetch), or we use the\nconfigured refspec (which again spells what should happen).\n\nThe updated rule would be more complex. If a remote nickname is\nused, and a refspec given from the command line is without colon, a\nnew special rule overrides the current behaviour and tries to match\nwith a configured refspec. You would need to desribe what happens\nin that case.\n"},{"id":"197052","messageId":"502BECAD.90307@ira.uka.de","threadId":"31245","inReplyTo":"7vfw7o6p1g.fsf@alter.siamese.dyndns.org","subject":"Re: Your branch and 'origin/master' have diverged","fromName":"Holger Hellmuth (IKS)","fromEmail":"hellmuth@ira.uka.de","sentAt":"2012-08-15T18:38:37Z","receivedAt":"2012-08-15T18:38:37Z","isPatch":false,"sender":{"key":"hellmuth@ira.uka.de","avatar":null},"body":"Am 15.08.2012 19:30, schrieb Junio C Hamano:\n> The current rule is very\n> simple and understandable. You either say from the command line\n> exactly what should happen (refspec without colon is the same as the\n> refspec with colon at the end, meaning \"do not track\"; if you want\n> to track, you write what to update with the fetch), or we use the\n> configured refspec (which again spells what should happen).\n\nCouldn't a similar new rule just say that refspec is a short for \n: ?\n\nThe exception would be in the case of a URL as remote, but that would \nnot be surprising to anyone, as there is no obvious target for the update\n"},{"id":"197056","messageId":"7vehn855yo.fsf@alter.siamese.dyndns.org","threadId":"31245","inReplyTo":"502BECAD.90307@ira.uka.de","subject":"Re: Your branch and 'origin/master' have diverged","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2012-08-15T19:07:59Z","receivedAt":"2012-08-15T19:07:59Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"\"Holger Hellmuth (IKS)\" writes:\n\n> Am 15.08.2012 19:30, schrieb Junio C Hamano:\n>> The current rule is very\n>> simple and understandable. You either say from the command line\n>> exactly what should happen (refspec without colon is the same as the\n>> refspec with colon at the end, meaning \"do not track\"; if you want\n>> to track, you write what to update with the fetch), or we use the\n>> configured refspec (which again spells what should happen).\n>\n> Couldn't a similar new rule just say that refspec is a short\n> for : ?\n\nOf course not.\n"},{"id":"197057","messageId":"7va9xw55aj.fsf@alter.siamese.dyndns.org","threadId":"31245","inReplyTo":"7vfw7o6p1g.fsf@alter.siamese.dyndns.org","subject":"Re: Your branch and 'origin/master' have diverged","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2012-08-15T19:22:28Z","receivedAt":"2012-08-15T19:22:28Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Junio C Hamano writes:\n\n> Updating Documentation/pull-fetch-param.txt would be a bear, though.\n> The documentation is stale in that it was written in the days back\n> when .git/remotes/ was the primary way to configure remotes, and was\n> not adjusted to use the termilology used in the [remote \"where\"]\n> section of the .git/config file (notice a mention of \"'Pull: '\n> lines\" there), so it needs cosmetic adjustment anyway, but the\n> semantics it spells is still up to date. The current rule is very\n> simple and understandable. You either say from the command line\n> exactly what should happen (refspec without colon is the same as the\n> refspec with colon at the end, meaning \"do not track\"; if you want\n> to track, you write what to update with the fetch), or we use the\n> configured refspec (which again spells what should happen).\n>\n> The updated rule would be more complex. If a remote nickname is\n> used, and a refspec given from the command line is without colon, a\n> new special rule overrides the current behaviour and tries to match\n> with a configured refspec. You would need to desribe what happens\n> in that case.\n\nIt would be something like this.\n\nWhen you tell \"git fetch\" to fetch one or more refs from a\nconfigured remote by explicitly listing them on the command line,\ne.g.\n\n git fetch ...\n\neach ... goes through the following process:\n\n - The is turned into the full ref at the remote that\n starts from refs/ form by applying the usual fetch dwimmery\n (if is a name of a branch, \"refs/heads/\" would\n likely to be the one that is fetched).\n\n - Then, configured fetch refspecs for is looked up from\n remote..fetch configuration variable(s), or \"Pull: \"\n line(s) of .git/remotes/ file.\n\n - If the LHS of a refspec found in the previous step matches the\n full ref we computed in the first step, then the ref at the\n RHS of the refspec (i.e. remote tracking branch), if any, is\n updated.\n\nIf there is no configured refspecs that match the name given from\nthe command line, no remote tracking ref is updated.\n"},{"id":"197104","messageId":"20120816162142.GC2853@sigill.intra.peff.net","threadId":"31245","inReplyTo":"87sjbo63pl.fsf@thomas.inf.ethz.ch","subject":"Re: Your branch and 'origin/master' have diverged","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2012-08-16T16:21:42Z","receivedAt":"2012-08-16T16:21:42Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Wed, Aug 15, 2012 at 08:59:02AM +0200, Thomas Rast wrote:\n\n> I have never had a need for a fetch that doesn't update the remote\n> namespace, nor heard anyone on IRC who has. OTOH, I do have anecdotal\n> evidence in support of \"the current state is confusing\": this thread, or\n> the fact that Jan's IRC bot grew bot-quotes !fetch4/!pull4 that people\n> use to warn users of 'git pull origin master' (it's apparently very\n> common).\n> \n> The 1.8.0 thread is here, and Peff even said he had a patch he uses in\n> his tree:\n> \n> http://thread.gmane.org/gmane.comp.version-control.git/165720/focus=165758\n> \n> There's even a newer thread suggesting the same:\n> \n> http://thread.gmane.org/gmane.comp.version-control.git/192252\n\nYeah, I have been running with that patch for ages, and it has never\nbeen a problem for me. Of course, the problem cases are very specific\nworkflows that I do not happen to use. There are definitely regressions\nfor some workflows; the question is whether or not anybody is using\nthose workflows (and/or would be bothered to adapt to using the reflog\ninstead).\n\nAlso note that there are several test failures with the patch, but I\nhaven't investigated them (i.e., I don't know if the patch is buggy, if\nit is breaking a test in a way that is different than the expected\nregression, or if the test simply happens to depend on the current\nbehavior and should be fixed).\n\n-Peff\n"},{"id":"197106","messageId":"20120816162417.GD2853@sigill.intra.peff.net","threadId":"31245","inReplyTo":"7va9xw55aj.fsf@alter.siamese.dyndns.org","subject":"Re: Your branch and 'origin/master' have diverged","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2012-08-16T16:24:18Z","receivedAt":"2012-08-16T16:24:18Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Wed, Aug 15, 2012 at 12:22:28PM -0700, Junio C Hamano wrote:\n\n> > The updated rule would be more complex. If a remote nickname is\n> > used, and a refspec given from the command line is without colon, a\n> > new special rule overrides the current behaviour and tries to match\n> > with a configured refspec. You would need to desribe what happens\n> > in that case.\n> \n> It would be something like this.\n> \n> When you tell \"git fetch\" to fetch one or more refs from a\n> configured remote by explicitly listing them on the command line,\n> e.g.\n> \n> git fetch ...\n> \n> each ... goes through the following process:\n> \n> - The is turned into the full ref at the remote that\n> starts from refs/ form by applying the usual fetch dwimmery\n> (if is a name of a branch, \"refs/heads/\" would\n> likely to be the one that is fetched).\n> \n> - Then, configured fetch refspecs for is looked up from\n> remote..fetch configuration variable(s), or \"Pull: \"\n> line(s) of .git/remotes/ file.\n> \n> - If the LHS of a refspec found in the previous step matches the\n> full ref we computed in the first step, then the ref at the\n> RHS of the refspec (i.e. remote tracking branch), if any, is\n> updated.\n> \n> If there is no configured refspecs that match the name given from\n> the command line, no remote tracking ref is updated.\n\nThat is almost exactly what my patch does, except I am not sure that it\nrespects the \"without a colon\" bit from your first message. In other\nwords, any time it sees that we have fetched a ref from a particular\nremote, it applies the mapping from the config and adds the result to\nthe list of refs to be updated.\n\n-Peff\n"},{"id":"197111","messageId":"7vsjbm1zz1.fsf@alter.siamese.dyndns.org","threadId":"31245","inReplyTo":"20120816162417.GD2853@sigill.intra.peff.net","subject":"Re: Your branch and 'origin/master' have diverged","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2012-08-16T17:57:54Z","receivedAt":"2012-08-16T17:57:54Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jeff King writes:\n\n> On Wed, Aug 15, 2012 at 12:22:28PM -0700, Junio C Hamano wrote:\n>\n>> > The updated rule would be more complex. If a remote nickname is\n>> > used, and a refspec given from the command line is without colon, a\n>> > new special rule overrides the current behaviour and tries to match\n>> > with a configured refspec. You would need to desribe what happens\n>> > in that case.\n>> \n>> It would be something like this.\n>> \n>> When you tell \"git fetch\" to fetch one or more refs from a\n>> configured remote by explicitly listing them on the command line,\n>> e.g.\n>> \n>> git fetch ...\n>> \n>> each ... goes through the following process:\n>>\n>> - The is turned into the full ref at the remote that\n>> starts from refs/ form by applying the usual fetch dwimmery\n>> (if is a name of a branch, \"refs/heads/\" would\n>> likely to be the one that is fetched).\n>> \n>> - Then, configured fetch refspecs for is looked up from\n>> remote..fetch configuration variable(s), or \"Pull: \"\n>> line(s) of .git/remotes/ file.\n>> \n>> - If the LHS of a refspec found in the previous step matches the\n>> full ref we computed in the first step, then the ref at the\n>> RHS of the refspec (i.e. remote tracking branch), if any, is\n>> updated.\n>> \n>> If there is no configured refspecs that match the name given from\n>> the command line, no remote tracking ref is updated.\n>\n> That is almost exactly what my patch does, except I am not sure that it\n> respects the \"without a colon\" bit from your first message.\n\nYeah, I forgot to repeat it in this message, but the above\nthree-bullet list needs the 0-th item\n\n - If has already colon in it, following special case rules\n do not apply.\n\nin front of it.\n\nEven though I suspect the updated behaviour may be more useful for\ncasual users (while making the semantics a bit more difficult to\nexplain, like the above documentation update), it is a major\nregression to existing users if it closes the last escape hatch, so\nI guess with your patch we are almost there but not quite there yet.\n"}]}