{"thread":{"id":"2858","subject":"bad git pull","startedAt":"2005-12-15T23:37:47Z","lastAt":"2005-12-18T17:16:02Z","messageCount":22,"participants":["Don Zickus","Junio C Hamano","Carl Baldwin","Morten Welinder","Linus Torvalds","Nicolas Pitre"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"13708","messageId":"68948ca0512151537v2d8f22c8x962c55bd507af8cf@mail.gmail.com","threadId":"2858","inReplyTo":null,"subject":"bad git pull","fromName":"Don Zickus","fromEmail":"dzickus@gmail.com","sentAt":"2005-12-15T23:37:47Z","receivedAt":"2005-12-15T23:37:47Z","isPatch":false,"sender":{"key":"dzickus@gmail.com","avatar":"https://gravatar.com/avatar/fbc96d0d5584c05dec11867b861650fe9f5d7d0ddec2655a1f90542fe07d9769?d=mp&s=160"},"body":"Hello,\n\nI notice if I create a branch (and switch to it) in the linux kernel\noff of say version 2.6.14, then later do a git pull, things get ugly. \nIt seems like all the upstream changes are being merged into the\n2.6.14 branch (instead of the latest kernel tag).\n\nIs this a user error because the tool is still fragile?\n\nThanks,\nDon\n"},{"id":"13710","messageId":"7vzmn2kjw1.fsf@assigned-by-dhcp.cox.net","threadId":"2858","inReplyTo":"68948ca0512151537v2d8f22c8x962c55bd507af8cf@mail.gmail.com","subject":"Re: bad git pull","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2005-12-15T23:42:06Z","receivedAt":"2005-12-15T23:42:06Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Don Zickus writes:\n\n> I notice if I create a branch (and switch to it) in the linux kernel\n> off of say version 2.6.14, then later do a git pull, things get ugly. \n> It seems like all the upstream changes are being merged into the\n> 2.6.14 branch (instead of the latest kernel tag).\n>\n> Is this a user error because the tool is still fragile?\n\nI do not understand the question.\n\nThe user wanted all the good developments from the mainline into\nthe fork he created starting at 2.6.14, and the tool did what\nwas asked. Why would you want to forbid that from happening,\nand what did you want to happen instead?\n"},{"id":"13711","messageId":"7vu0d9lxx9.fsf@assigned-by-dhcp.cox.net","threadId":"2858","inReplyTo":"7vzmn2kjw1.fsf@assigned-by-dhcp.cox.net","subject":"Re: bad git pull","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2005-12-15T23:53:38Z","receivedAt":"2005-12-15T23:53:38Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Junio C Hamano writes:\n\n> Don Zickus writes:\n>\n>> I notice if I create a branch (and switch to it) in the linux kernel\n>> off of say version 2.6.14, then later do a git pull, things get ugly. \n>> It seems like all the upstream changes are being merged into the\n>> 2.6.14 branch (instead of the latest kernel tag).\n>>\n>> Is this a user error because the tool is still fragile?\n>\n> I do not understand the question.\n>\n> The user wanted all the good developments from the mainline into\n> the fork he created starting at 2.6.14, and the tool did what\n> was asked. Why would you want to forbid that from happening,\n> and what did you want to happen instead?\n\nActually I think I do understand the question. You have a clone\nof linux-2.6 repository, and your \"origin\" branch tracks the\nbleeding edge from Linus. You also have \"myhack\" branch that\nwas forked off from 2.6.14, and wanted to see what new things\nLinus has by updating \"origin\", and perhaps merge those changes\ninto your \"master\" which keeps track of your hacks based on\nLinus tip, but unfortunately you were on \"myhack\" branch.\n\nOuch.\n\nSo what you wanted to do was probably:\n\n\t$ git fetch ;# this updates \"origin\" to Linus tip\n\ninstead of\n\n\t$ git pull ;# this updates \"origin\" to Linus tip *and*\n # merges that into the current branch\n\nAs you may probably know, you can recover by\n\n\t$ git reset --hard\n\nWhile I am sympathetic, this \"Oops, I said pull when I meant\nfetch\" sounds remotely similar to \"oops, I said 'rm -r' when I\nmeant to say 'ls -r'\". Is it that the tool is too fragile?\n"},{"id":"13727","messageId":"68948ca0512160739g12a3e25en256bae8c354c3a45@mail.gmail.com","threadId":"2858","inReplyTo":"7vu0d9lxx9.fsf@assigned-by-dhcp.cox.net","subject":"Re: bad git pull","fromName":"Don Zickus","fromEmail":"dzickus@gmail.com","sentAt":"2005-12-16T15:39:27Z","receivedAt":"2005-12-16T15:39:27Z","isPatch":false,"sender":{"key":"dzickus@gmail.com","avatar":"https://gravatar.com/avatar/fbc96d0d5584c05dec11867b861650fe9f5d7d0ddec2655a1f90542fe07d9769?d=mp&s=160"},"body":"> While I am sympathetic, this \"Oops, I said pull when I meant\n> fetch\" sounds remotely similar to \"oops, I said 'rm -r' when I\n> meant to say 'ls -r'\". Is it that the tool is too fragile?\n>\n\nSorry, wrong choice of words. Didn't mean to imply anything negative.\nThough, I am still learning the tool and its features, I do appreciate\nyour feedback and your last email was correct in understanding the\nmess I created. I'll go read up on the differences between 'fetch'\nand 'pull'.\n\nCheers,\nDon\n"},{"id":"13729","messageId":"20051216172535.GA25856@hpsvcnb.fc.hp.com","threadId":"2858","inReplyTo":"7vu0d9lxx9.fsf@assigned-by-dhcp.cox.net","subject":"Re: bad git pull","fromName":"Carl Baldwin","fromEmail":"cnb@fc.hp.com","sentAt":"2005-12-16T17:25:35Z","receivedAt":"2005-12-16T17:25:35Z","isPatch":false,"sender":{"key":"cnb@fc.hp.com","avatar":null},"body":"Hello,\n\nHere are my two cents. I'll try my best to make a case for those poor\nsouls who get into this sort of mess.\n\nWhenever I give a colleage an introduction to git I emphatically\nrecommend that they start with using git fetch and git merge\nindependantly of each other and stay away for git pull at least until\nthey know what they're doing. This is because I have found that people\nare really surprised at what happens when they type git pull until it\nreally sinks in that 'pull = fetch + merge to current branch, whatever\nthat may be'.\n\nThe difference between the words fetch and pull is much more subtle than\nthe difference between remove and list which are the basis for the\ncommands rm and ls. I see nothing in the English dictionary to suggest\nthat pull means fetch + merge. This is a gitism. Even after reading\ndocumentation clearly and even using git for a while the difference\nreally takes some time to sink in.\n\nI think a great degree of understanding should be shown toward those who\ndig themselves into this kind of thing. I also recommend that some\nextra care should be taken in the tutorials and documentation to warn\nabout this difference up front and possibly suggest avoiding the use of\npull for those new to git.\n\nCarl\n\nPS The issue was exacerbated when cogito and git were inconsistent on\ntheir respective usages of pull and fetch. I think this has gone away,\nhasn't it? I haven't used cogito in some time so I really don't know.\n\nOn Thu, Dec 15, 2005 at 03:53:38PM -0800, Junio C Hamano wrote:\n> Junio C Hamano writes:\n> \n> > Don Zickus writes:\n> >\n> >> I notice if I create a branch (and switch to it) in the linux kernel\n> >> off of say version 2.6.14, then later do a git pull, things get ugly. \n> >> It seems like all the upstream changes are being merged into the\n> >> 2.6.14 branch (instead of the latest kernel tag).\n> >>\n> >> Is this a user error because the tool is still fragile?\n> >\n> > I do not understand the question.\n> >\n> > The user wanted all the good developments from the mainline into\n> > the fork he created starting at 2.6.14, and the tool did what\n> > was asked. Why would you want to forbid that from happening,\n> > and what did you want to happen instead?\n> \n> Actually I think I do understand the question. You have a clone\n> of linux-2.6 repository, and your \"origin\" branch tracks the\n> bleeding edge from Linus. You also have \"myhack\" branch that\n> was forked off from 2.6.14, and wanted to see what new things\n> Linus has by updating \"origin\", and perhaps merge those changes\n> into your \"master\" which keeps track of your hacks based on\n> Linus tip, but unfortunately you were on \"myhack\" branch.\n> \n> Ouch.\n> \n> So what you wanted to do was probably:\n> \n> \t$ git fetch ;# this updates \"origin\" to Linus tip\n> \n> instead of\n> \n> \t$ git pull ;# this updates \"origin\" to Linus tip *and*\n> # merges that into the current branch\n> \n> As you may probably know, you can recover by\n> \n> \t$ git reset --hard\n> \n> While I am sympathetic, this \"Oops, I said pull when I meant\n> fetch\" sounds remotely similar to \"oops, I said 'rm -r' when I\n> meant to say 'ls -r'\". Is it that the tool is too fragile?\n> \n> \n> -\n> To unsubscribe from this list: send the line \"unsubscribe git\" in\n> the body of a message to majordomo@vger.kernel.org\n> More majordomo info at http://vger.kernel.org/majordomo-info.html\n> \n\n-- \n- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -\n Carl Baldwin Systems VLSI Laboratory\n Hewlett Packard Company\n MS 88 work: 970 898-1523\n 3404 E. Harmony Rd. work: Carl.N.Baldwin@hp.com\n Fort Collins, CO 80525 home: Carl@ecBaldwin.net\n- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -\n"},{"id":"13730","messageId":"7v3bktj5ya.fsf@assigned-by-dhcp.cox.net","threadId":"2858","inReplyTo":"68948ca0512160739g12a3e25en256bae8c354c3a45@mail.gmail.com","subject":"Re: bad git pull","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2005-12-16T17:40:45Z","receivedAt":"2005-12-16T17:40:45Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Don Zickus writes:\n\n>> While I am sympathetic, this \"Oops, I said pull when I meant\n>> fetch\" sounds remotely similar to \"oops, I said 'rm -r' when I\n>> meant to say 'ls -r'\". Is it that the tool is too fragile?\n>\n> Sorry, wrong choice of words. Didn't mean to imply anything negative.\n> Though, I am still learning the tool and its features, I do appreciate\n> your feedback and your last email was correct in understanding the\n> mess I created. I'll go read up on the differences between 'fetch'\n> and 'pull'.\n\nI too was a bit too defensive, and I agree the tool is prone to\neasy errors; the worst part is that there is no \"rm -i\"\nequivalent to be extra careful [*1*]. On the other hand, we\nhave \"git reset\" to recover from, so it is not as bad as\na mistake with \"rm\" ;-).\n\nIf for example there were a way to say \"this `origin' shortcut\nis to be pulled into `master' branch and nothing else\", we could\nhave caught the \"git pull\" you had trouble with. There was a\ndiscussion on the list in the past to extend remotes/ files to\nallow such restriction of the patchflow to be expressed, but\nback then I felt the kind of restriction the proposal could\nexpress was too limiting, and the discussion was a bit premature\nbecause we did not have recommended patterns yet.\n\nWe might want to revive the discussion post 1.0. Taking the\nexample of the topic-branch workflow by Tony, the \"patch flow\"\nlanguage needs to be able to express something at least this:\n\n - topic branches -- branched from 'origin' somewhere in the\n past; commits accumulated but usually nothing is merged\n into them.\n\n - 'test' -- branched from 'origin' somewhere in the past; used\n solely to merge topic branches into it and no commits are\n made into it directly; branches that are regularly merged\n into it are:\n\n - topic branches\n - 'origin'\n - 'release'\n\n - 'release' -- branched from 'origin' somewhere in the\n past; trivial/obviously correct commits are made into it\n directly; proven to be good topic branches are merged into it\n for consumption by others; branches that are regularly merged\n into it are:\n\n - topic branches\n - 'origin'\n - never 'test' \n\n\n\n[Footnote]\n\n*1* IMHO \"rm -i\" is not that safe, though. If one overuses it,\nit trains one's fingers to say \"y\" without much thinking.\n"},{"id":"13732","messageId":"118833cc0512161007k38fdd15w2dcdf0c93f26d29e@mail.gmail.com","threadId":"2858","inReplyTo":"7vu0d9lxx9.fsf@assigned-by-dhcp.cox.net","subject":"Re: bad git pull","fromName":"Morten Welinder","fromEmail":"mwelinder@gmail.com","sentAt":"2005-12-16T18:07:16Z","receivedAt":"2005-12-16T18:07:16Z","isPatch":false,"sender":{"key":"mwelinder@gmail.com","avatar":null},"body":"> While I am sympathetic, this \"Oops, I said pull when I meant\n> fetch\" sounds remotely similar to \"oops, I said 'rm -r' when I\n> meant to say 'ls -r'\". Is it that the tool is too fragile?\n\nDidn't bk come with some kind of (one-level) undo pull? It should not\nbe too hard to create something similar considering that one could\njust leave new objects in the db orphaned.\n\nM.\n"},{"id":"13733","messageId":"7vk6e4hmrj.fsf@assigned-by-dhcp.cox.net","threadId":"2858","inReplyTo":"20051216172535.GA25856@hpsvcnb.fc.hp.com","subject":"Re: bad git pull","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2005-12-16T19:20:32Z","receivedAt":"2005-12-16T19:20:32Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Carl Baldwin writes:\n\n> Whenever I give a colleage an introduction to git I emphatically\n> recommend that they start with using git fetch and git merge\n> independantly of each other and stay away for git pull at least until\n> they know what they're doing.\n\nYou \"reduced\" this sequence:\n\n\t$ git symbolic-ref HEAD ;# to make sure you are on the branch\n # you think you are on\n\t$ git pull\n\nto this sequence:\n\n\t$ git fetch origin ;# would not damage the repository\n\t$ git symbolic-ref HEAD ;# to make sure you are on the branch\n # you think you are on\n\t$ git merge \"Merge from frotz branch of git://...\" HEAD FETCH_HEAD\n\nThe thing is, you need to make sure where you are, in either\ncase, before the actual merge happens. Yours needs extra\ntyping, and in addition loses the merge message autogenerated by\n\"git pull\". Sorry, I fail to see how that is an improvement.\n\n> I see nothing in the English dictionary to suggest that pull\n> means fetch + merge.\n\nI agree to this. I have never used BK so this is just a\nspeculation, but I suspect what happened is that we inherited\n\"pull\" terminology from there, needed to name the merge-less\npart something, and we ended up calling it \"fetch\". So the\nhistory behind them might be expressed better by \"fetch = pull -\nmerge\" instead of saying \"pull = fetch + merge\" ;-).\n\n> ... I also recommend that some\n> extra care should be taken in the tutorials and documentation to warn\n> about this difference up front and possibly suggest avoiding the use of\n> pull for those new to git.\n\nYup. Thanks for the comments. I am not a good writer, so a\npatch is greatly appreciated.\n\nBTW, I feel that setting Mail-Followup-To: to other people is\njust plain rude.\n\n Mail-Followup-To: Junio C Hamano ,\n Don Zickus , git@vger.kernel.org\n\nI suspect you are trying to avoid receiving a duplicate message\nbecause you subscribe to the list, but when I tell my MUA \"I\nwant to say something to the author of this message in public\" I\nget Don Zickus on the To: line instead of you, and I had to edit\nthe To: line to point at you. Aren't you forcing me (and other\npeople who might want to follow-up to your message) to do extra\nwork, and making Don's life harder [*1*], just to work around\nthe problem on your end, when you could just filter the incoming\nduplicates yourself?\n\nRemoving yourself from CC: line when the CC: line already\ncontains the mailing list you subscribe to would be fine, but I\nfind this use of Mail-Followup-To: somewhat objectionable.\n\n[Footnote]\n\n*1* Don could have a mail sorter that prioritizes messages\naddressed To: over Cc: him, and response meant to *you* goes\nwith To: Don --- which messes up such a mail sorting rule.\n"},{"id":"13734","messageId":"7vfyoshmp6.fsf@assigned-by-dhcp.cox.net","threadId":"2858","inReplyTo":"118833cc0512161007k38fdd15w2dcdf0c93f26d29e@mail.gmail.com","subject":"Re: bad git pull","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2005-12-16T19:21:57Z","receivedAt":"2005-12-16T19:21:57Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Morten Welinder writes:\n\n>> While I am sympathetic, this \"Oops, I said pull when I meant\n>> fetch\" sounds remotely similar to \"oops, I said 'rm -r' when I\n>> meant to say 'ls -r'\". Is it that the tool is too fragile?\n>\n> Didn't bk come with some kind of (one-level) undo pull? It should not\n> be too hard to create something similar considering that one could\n> just leave new objects in the db orphaned.\n\nYes, that is called \"git reset\".\n"},{"id":"13748","messageId":"Pine.LNX.4.64.0512161347490.3698@g5.osdl.org","threadId":"2858","inReplyTo":"7vfyoshmp6.fsf@assigned-by-dhcp.cox.net","subject":"Re: bad git pull","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2005-12-16T22:12:08Z","receivedAt":"2005-12-16T22:12:08Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Fri, 16 Dec 2005, Junio C Hamano wrote:\n>\n> Morten Welinder writes:\n> \n> >> While I am sympathetic, this \"Oops, I said pull when I meant\n> >> fetch\" sounds remotely similar to \"oops, I said 'rm -r' when I\n> >> meant to say 'ls -r'\". Is it that the tool is too fragile?\n> >\n> > Didn't bk come with some kind of (one-level) undo pull? It should not\n> > be too hard to create something similar considering that one could\n> > just leave new objects in the db orphaned.\n> \n> Yes, that is called \"git reset\".\n\nWell, this is one area where BK and git differ a lot. BK didn't overload \nmany things onto the same \"reset\" functionality, but had specific \noperations for specific cases.\n\nAlso BK would never leave a merge in the git kind of half-merged state, \nbecause BK refuses to have two branches open. Instead, BK had a special \nway of handling merges, which worked fine but quite frankly I have very \nlittle idea of how it worked (it was some kind of \"shadow BK tree\", it was \ncalled \".bk/RESOLVE/\" or something like that - but because the tools \nwere so nice, you never really had any reason to look into it, so I \ndon't know what it did).\n\nBK would never change the working tree itself until the merge was done, so \nyou would never need to do what a plain \"git reset --hard\" (without any \narguments) does.\n\nIn many ways the BK thing was very nice, although the git way is perhaps a \nbit more flexible (because git makes the intermediate tree visible you can \neasily edit the merge errors, and compile/test the result, before you \ndecide to commit any manual merge).\n\nI really do like the way git does merges now (especially after the last \nround of git-diff-tree fixes that allow comparing the different stages), \nbut the BK way is in some ways cleaner and leaves less potential for \nconfusion since it avoids ever exposing you to any half-merged state.\n\nYou may remember how I initially argued that we should always try to merge \nstuff outside of the normal working directory. And I still _like_ that \napproach, although I've since decided that I actually prefer the current \ngit way is even better in practice.\n\nBut \"git reset\" is a lot more than the \"revert to previous state\". It \n_also_ does - without the error checking - what \"bk fix\" used to do \n(which is to undo the last commit, so that you can re-commit it), and it \nalso does what \"bk undo\" used to do. It also does \"bk unpull\".\n\nSo \"git reset\" really does a whole lot of different and _mostly_ related \nthings:\n\n - undo any half-way changes (very similar to just \"git checkout -f\"), and \n just reset to the state of the last successful commit (ie \"current \n HEAD\"):\n\n\tgit reset --hard\n\n BK didn't need this, although if you just want to remove your edits \n (which \"git reset --hard\" also does), you could - like with git - just \n do a \"checkout\" operation, of course.\n\n - undo the last commit, but don't undo the working tree (\"soft reset to\n parent of head\").\n\n\tgit reset HEAD^\n\n I think this was \"bk fix -C\".\n\n - undo the last commit entirely (\"hard reset to previous state\"):\n\n\tgit reset --hard HEAD^\n\n This was \"bk undo\"\n\n - undo the last pull (\"bk unpull\"): \"hard reset to ORIG_HEAD\":\n\n\tgit reset --hard ORIG_HEAD\n\n This was \"bk unpull\".\n\nwhere the last two are obviously just special cases of a generic \"undo to \narbitrary previous commit state\".\n\nBK in many ways had more hand-holding (which I think is good, and \"git\" to \nsome degree has an unnecessarily \"hard core\" approach to these things). \n\nFor example, I think \"bk undo\" not only asked you about it, but it also \nonly ever undid the last commit (and refused to undo a pull or merge). If \nyou wanted to undo to some arbitrary state, you had to use the \"-a\" flag, \niirc. \n\nOf course, under BK the \"undo\" operation was final, so BK _had_ to be more \ncareful. With git, if you undo to some arbitrary state, you can still \n\"re-do\" all your commits if you just find the old head (and \ngit-fsck-objects will help you do that), so in that sense git doesn't \n_need_ to be as careful as BK was.\n\n\t\tLinus\n"},{"id":"13753","messageId":"118833cc0512161637v1d180f9fh66a7dc6d3fe11d2b@mail.gmail.com","threadId":"2858","inReplyTo":"Pine.LNX.4.64.0512161347490.3698@g5.osdl.org","subject":"Re: bad git pull","fromName":"Morten Welinder","fromEmail":"mwelinder@gmail.com","sentAt":"2005-12-17T00:37:18Z","receivedAt":"2005-12-17T00:37:18Z","isPatch":false,"sender":{"key":"mwelinder@gmail.com","avatar":null},"body":"> - undo the last commit entirely (\"hard reset to previous state\"):\n>\n> git reset --hard HEAD^\n>\n> This was \"bk undo\"\n>\n> - undo the last pull (\"bk unpull\"): \"hard reset to ORIG_HEAD\":\n>\n> git reset --hard ORIG_HEAD\n>\n> This was \"bk unpull\".\n\nIt would be outright peachy if Documentation/git-commit.txt and\nDocumentation/git-pull.txt mentioned these. That is certainly\nwhere I would look first to answer the \"what if I screwed up?\"\nquestion.\n\nMorten\n"},{"id":"13754","messageId":"Pine.LNX.4.64.0512161701400.3698@g5.osdl.org","threadId":"2858","inReplyTo":"118833cc0512161637v1d180f9fh66a7dc6d3fe11d2b@mail.gmail.com","subject":"Re: bad git pull","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2005-12-17T01:05:41Z","receivedAt":"2005-12-17T01:05:41Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Fri, 16 Dec 2005, Morten Welinder wrote:\n> \n> It would be outright peachy if Documentation/git-commit.txt and\n> Documentation/git-pull.txt mentioned these. That is certainly\n> where I would look first to answer the \"what if I screwed up?\"\n> question.\n\nIt might be even better to have some of the \"safe\" versions around. Ie \nsomething that refuses to \"undo\" a merge (you want to \"unpull\" it or \n\"unmerge\" it), and refuses to \"undo\" when there's a ORIG_HEAD around that \nimplies that the last commit was a \"pull\" (in which case again \"undo\" may \nbe the wrong thing to do, since it will only undo _one_ commit, even \nthough the pull might have fast-forwarded a _lot_ of commits).\n\nOf course, if we do that, we should also make sure that \"git commit\" \nremoves ORIG_HEAD. \n\nOr maybe \"git commit\" should always _write_ ORIG_HEAD with the old head, \nso that we can always do an \"undo\" by doing \"git reset --hard ORIG_HEAD\" \nregardless of whether the last thing was a \"git commit\" or a \"git pull\".\n\nHmm?\n\n\t\tLinus\n"},{"id":"13756","messageId":"7vy82kbiho.fsf@assigned-by-dhcp.cox.net","threadId":"2858","inReplyTo":"Pine.LNX.4.64.0512161701400.3698@g5.osdl.org","subject":"Re: bad git pull","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2005-12-17T01:49:23Z","receivedAt":"2005-12-17T01:49:23Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Linus Torvalds writes:\n\n> Or maybe \"git commit\" should always _write_ ORIG_HEAD with the old head, \n> so that we can always do an \"undo\" by doing \"git reset --hard ORIG_HEAD\" \n> regardless of whether the last thing was a \"git commit\" or a \"git pull\".\n>\n> Hmm?\n\nIf we define \"git undo\" as \"Revert the tree to the state one\nbefore the last successfull commit/pull\", then overwriting\nORIG_HEAD as you say at the commit time and always using \"git\nreset --hard ORIG_HEAD\" would make sense.\n\nI fail to see the merit of \"git undo/unpull/unmerge/...\"; mostly\nbecause I have never seen BK and do not benefit from the\nfamiliarity factor at all. To people without BK experience,\nhaving too many synonyms (e.g. \"git undo\" does something magical\nby feeding \"git reset --hard\" with ORIG_HEAD) might be just more\nnoise and confusion. I can see them asking \"why are there two\nways to do identical things?\".\n\nHowever, the reason I am maintaining git is not to make it\nuseful for _me_, but to make it useful for the kernel people, so\nif these BK-like synonyms help them, I'm all for it. If we are\ngoing to do that, somebody needs to describe what should each\ncommand do in each case in detail, because I do not know BK at\nall.\n\nYou guys were on BK for how many months, and have been on git\nfor how many months now? Do BK-familiarity factor matter, and\nwill it continue to matter for how long?\n"},{"id":"13757","messageId":"7vlkykbh42.fsf@assigned-by-dhcp.cox.net","threadId":"2858","inReplyTo":"118833cc0512161637v1d180f9fh66a7dc6d3fe11d2b@mail.gmail.com","subject":"Re: bad git pull","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2005-12-17T02:19:09Z","receivedAt":"2005-12-17T02:19:09Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Morten Welinder writes:\n\n>> - undo the last commit entirely (\"hard reset to previous state\"):\n>>\n>> - undo the last pull (\"bk unpull\"): \"hard reset to ORIG_HEAD\":\n>\n> It would be outright peachy if Documentation/git-commit.txt and\n> Documentation/git-pull.txt mentioned these. That is certainly\n> where I would look first to answer the \"what if I screwed up?\"\n> question.\n\nYup. Maybe one line comment at the bottom of these manual pages\npointing at git-reset manual page (which has nice examples\nsection) would be good enough?\n\n-- >8 --\n[PATCH] Examples of resetting.\n\nMorten Welinder says examples of resetting is really about\nrecovering from botched commit/pulls. I agree that pointers\nfrom commands that cause a reset to be needed in the first place\nwould be very helpful.\n\nAlso reset examples did not mention \"pull/merge\" cases.\n\nSigned-off-by: Junio C Hamano \n---\ndiff --git a/Documentation/git-commit.txt b/Documentation/git-commit.txt\nindex b92cf48..8b91f22 100644\n--- a/Documentation/git-commit.txt\n+++ b/Documentation/git-commit.txt\n@@ -66,6 +66,10 @@ OPTIONS\n \tUpdate specified paths in the index file before committing.\n \n \n+If you make a commit and then found a mistake immediately after\n+that, you can recover from it with gitlink:git-reset[1].\n+\n+\n Author\n ------\n Written by Linus Torvalds and\ndiff --git a/Documentation/git-merge.txt b/Documentation/git-merge.txt\nindex 0cac563..4ce799b 100644\n--- a/Documentation/git-merge.txt\n+++ b/Documentation/git-merge.txt\n@@ -37,6 +37,11 @@ include::merge-options.txt[]\n include::merge-strategies.txt[]\n \n \n+If you tried a merge which resulted in a complex conflicts and\n+would want to start over, you can recover with\n+gitlink:git-reset[1].\n+\n+\n HOW MERGE WORKS\n ---------------\n \ndiff --git a/Documentation/git-pull.txt b/Documentation/git-pull.txt\nindex c65ca9a..3a7d385 100644\n--- a/Documentation/git-pull.txt\n+++ b/Documentation/git-pull.txt\n@@ -104,6 +104,11 @@ merge the remote `origin` head into the \n local `master` branch.\n \n \n+If you tried a pull which resulted in a complex conflicts and\n+would want to start over, you can recover with\n+gitlink:git-reset[1].\n+\n+\n SEE ALSO\n --------\n gitlink:git-fetch[1], gitlink:git-merge[1]\ndiff --git a/Documentation/git-reset.txt b/Documentation/git-reset.txt\nindex 0204891..c6a269b 100644\n--- a/Documentation/git-reset.txt\n+++ b/Documentation/git-reset.txt\n@@ -111,6 +111,39 @@ remain there.\n changes still in the working tree.\n ------------\n \n+Undo a merge or pull::\n++\n+------------\n+$ git pull <1>\n+Trying really trivial in-index merge...\n+fatal: Merge requires file-level merging\n+Nope.\n+...\n+Auto-merging nitfol\n+CONFLICT (content): Merge conflict in nitfol\n+Automatic merge failed/prevented; fix up by hand\n+$ git reset --hard <2>\n+\n+<1> try to update from the upstream resulted in a lot of\n+conflicts; you were not ready to spend a lot of time merging\n+right now, so you decide to do that later.\n+<2> \"pull\" has not made merge commit, so \"git reset --hard\"\n+which is a synonym for \"git reset --hard HEAD\" clears the mess\n+from the index file and the working tree.\n+\n+$ git pull . topic/branch <3>\n+Updating from 41223... to 13134...\n+Fast forward\n+$ git reset --hard ORIG_HEAD <4>\n+\n+<3> merge a topic branch into the current branch, which resulted\n+in a fast forward.\n+<4> but you decided that the topic branch is not ready for public\n+consumption yet. \"pull\" or \"merge\" always leaves the original\n+tip of the current branch in ORIG_HEAD, so resetting hard to it\n+brings your index file and the working tree back to that state,\n+and resets the tip of the branch to that commit.\n+------------\n \n Author\n ------\n"},{"id":"13762","messageId":"Pine.LNX.4.64.0512162342010.3698@g5.osdl.org","threadId":"2858","inReplyTo":"7vy82kbiho.fsf@assigned-by-dhcp.cox.net","subject":"Re: bad git pull","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2005-12-17T07:44:02Z","receivedAt":"2005-12-17T07:44:02Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Fri, 16 Dec 2005, Junio C Hamano wrote:\n> \n> You guys were on BK for how many months, and have been on git\n> for how many months now? Do BK-familiarity factor matter, and\n> will it continue to matter for how long?\n\nI don't think it is a huge deal, I suspect that people who used BK have a \nmuch easier time with git if only because they already understand the \nwhole distributed thing and about commits and merges.\n\nThat said, I think a lot of newbies might want to have a \"git undo\", and \nnot because of any BK history. Even if it just ends up being nothing but \nshorthand for \"git reset --hard ORIG_HEAD\".\n\n\t\tLinus\n"},{"id":"13763","messageId":"7v4q582htm.fsf@assigned-by-dhcp.cox.net","threadId":"2858","inReplyTo":"Pine.LNX.4.64.0512162342010.3698@g5.osdl.org","subject":"Re: bad git pull","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2005-12-17T09:28:37Z","receivedAt":"2005-12-17T09:28:37Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Linus Torvalds writes:\n\n> That said, I think a lot of newbies might want to have a \"git undo\", and \n> not because of any BK history. Even if it just ends up being nothing but \n> shorthand for \"git reset --hard ORIG_HEAD\".\n\nI agree to this in principle, but I am afraid \"git undo\" is too\ngeneric and fuzzy a term. Things you might possibly want to\nundo depends on what you did last [*1*]. In most undoable\ncases, \"reset --hard\" is almost right but most likely would\nresult in information loss.\n\nIf we want to really newbie-proof the \"undo\" command, I think\nthe hard ones are not the ones that can be approximated with\nreset ORIG_HEAD, but other \"No way to undo\" ones and \"Nothing to\nundo\" ones.\n\nEarlier on the list I gave an overview on merge for an unnamed\nperson with only an e-mail address, and one thing struck me as\nquite hard to explain was that there are two kinds of \"merge\nfailures\" --- ones that did not even start the merge and ones\nthat failed in the middle due to conflicts. Somebody totally\nnew to git, after seeing \"git pull\" to fail in the first kind,\nwould get scared and type \"git undo\". We could prevent doing\ndamage by making sure we remove ORIG_HEAD in \"Nothing to undo\"\nsituations, but if we say \"Nothing to undo\" when the user types\n\"git undo\" in such a situation, we will surely hear \"what do you\nmean? the command said failed to pull and I wanted to recover\nfrom that!\".\n\nIt also is not clear if it is wise to clear ORIG_HEAD for \"No\nway to undo\" ones. Doing so would rob useful undo information\nfrom people who know git and expect \"No way to undo\" ones do not\nmuck with the existing ORIG_HEAD.\n\nEven for the ones that we would do \"reset --hard ORIG_HEAD\",\nmany lose information, and \"undo\" to me implies \"undo only what\nthe last command messed up\", which is not what actually happens.\n\nThe word \"reset\" does not have that connotation -- it takes you\nto some defined state, which may be close to what you had before\nbut may not be exactly the same if you had local changes in your\ntree. HEAD, ORIG_HEAD, and HEAD^ are such defined states you\ncan go, and the user gives where he wants to go explicitly.\n\"undo\" does not really say where to go and hides halfway what we\ndo, without doing exactly what the user would expect (and cannot\nbe implemented fully unless we are willing to take a snapshot of\nworking tree, I suspect).\n\n[Appendix]\n\n*1* List of commands that a user might want to undo.\n\nA merge or non-merge commit, cherry-pick, and revert::\n\treset --hard HEAD^ ;# this can be helped by leaving ORIG_HEAD\n # but \"--hard\" is not quite right;\n # your working tree could have been\n # dirty at irrelevant paths\n\nA fetch fast-forwarding non-current branch::\n\tNo way to undo -- we do not keep the old information.\n\nA merge, that was fast-forward::\n\treset ORIG_HEAD ;# never \"--hard\" -- your working tree could\n # have been dirty and in this case\n # there is no information loss.\n\nA merge attempt, conflicted::\n\treset --hard ORIG_HEAD\n # again, \"--hard\" is not quite right --\n\t\t\t # your working tree could have been\n # dirty at irrelevant paths.\n\nA merge attempt, did not even start because index or tree was dirty::\n\tNothing to undo.\n\nA successful checkout (switch branch)::\n\tNo way to undo -- we do not keep the old information.\n\ngit-update-index and git-add::\n\tNo way to really undo -- we do not keep the old\n\tinformation. The closest is \"git reset\" but it reverts\n\tmore than the last operation.\n\nrebase::\n\treset --hard ORIG_HEAD\n\nam/applymbox::\n No way to undo -- we do not keep the old information.\n\t\t\t;# this can be helped by leaving ORIG_HEAD\n"},{"id":"13768","messageId":"Pine.LNX.4.64.0512171601430.26663@localhost.localdomain","threadId":"2858","inReplyTo":"7v4q582htm.fsf@assigned-by-dhcp.cox.net","subject":"Re: bad git pull","fromName":"Nicolas Pitre","fromEmail":"nico@cam.org","sentAt":"2005-12-17T21:04:37Z","receivedAt":"2005-12-17T21:04:37Z","isPatch":false,"sender":{"key":"nico@fluxnic.net","avatar":"https://avatars.githubusercontent.com/u/702790?v=4"},"body":"On Sat, 17 Dec 2005, Junio C Hamano wrote:\n\n> Linus Torvalds writes:\n> \n> > That said, I think a lot of newbies might want to have a \"git undo\", and \n> > not because of any BK history. Even if it just ends up being nothing but \n> > shorthand for \"git reset --hard ORIG_HEAD\".\n> \n> I agree to this in principle, but I am afraid \"git undo\" is too\n> generic and fuzzy a term. Things you might possibly want to\n> undo depends on what you did last [*1*]. In most undoable\n> cases, \"reset --hard\" is almost right but most likely would\n> result in information loss.\n\nOne observation is that ORIG_HEAD should probably be named PREV_HEAD in \nsuch context to make it more obvious what it is about.\n\n\nNicolas\n"},{"id":"13775","messageId":"7v8xujyuna.fsf@assigned-by-dhcp.cox.net","threadId":"2858","inReplyTo":"Pine.LNX.4.64.0512171601430.26663@localhost.localdomain","subject":"Re: bad git pull","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2005-12-18T03:02:49Z","receivedAt":"2005-12-18T03:02:49Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Nicolas Pitre writes:\n\n> One observation is that ORIG_HEAD should probably be named PREV_HEAD in \n> such context to make it more obvious what it is about.\n\nI do not see much difference either way, but I suspect ORIG_HEAD\nis pretty much well established by now.\n"},{"id":"13777","messageId":"Pine.LNX.4.64.0512172310060.26663@localhost.localdomain","threadId":"2858","inReplyTo":"7v8xujyuna.fsf@assigned-by-dhcp.cox.net","subject":"Re: bad git pull","fromName":"Nicolas Pitre","fromEmail":"nico@cam.org","sentAt":"2005-12-18T04:17:20Z","receivedAt":"2005-12-18T04:17:20Z","isPatch":false,"sender":{"key":"nico@fluxnic.net","avatar":"https://avatars.githubusercontent.com/u/702790?v=4"},"body":"On Sat, 17 Dec 2005, Junio C Hamano wrote:\n\n> Nicolas Pitre writes:\n> \n> > One observation is that ORIG_HEAD should probably be named PREV_HEAD in \n> > such context to make it more obvious what it is about.\n> \n> I do not see much difference either way,\n\nORIG suggests \"origin\" to me, something that was there first, or before \nanything else. If you want to undo something, you want its \"previous\" \nstate restored relative to the current state, not the absolute previous \n(first) one.\n\n> but I suspect ORIG_HEAD\n> is pretty much well established by now.\n\nWell, cogito for one doesn't care at all, and it even doesn't make for \nit to be created/updated.\n\nBut still it can remain for what it is now, and PREV_HEAD added for undo \npurpose.\n\nNot a big deal in any case though.\n\n\nNicolas\n"},{"id":"13778","messageId":"Pine.LNX.4.64.0512172231160.3698@g5.osdl.org","threadId":"2858","inReplyTo":"Pine.LNX.4.64.0512172310060.26663@localhost.localdomain","subject":"Re: bad git pull","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2005-12-18T06:31:55Z","receivedAt":"2005-12-18T06:31:55Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Sat, 17 Dec 2005, Nicolas Pitre wrote:\n> \n> ORIG suggests \"origin\" to me\n\nIt's meant to be short for ORIGinal, not ORIGin. That's how I wrote it and \nhave always read it ;)\n\n\t\tLinus\n"},{"id":"13780","messageId":"7vd5juub9h.fsf@assigned-by-dhcp.cox.net","threadId":"2858","inReplyTo":"Pine.LNX.4.64.0512172310060.26663@localhost.localdomain","subject":"Re: bad git pull","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2005-12-18T07:15:06Z","receivedAt":"2005-12-18T07:15:06Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Nicolas Pitre writes:\n\n>> I do not see much difference either way,\n>\n> ORIG suggests \"origin\" to me,...\n\nHmph.\n\nI always thought it was original-head before the operation\nhappened, which is why I said it is no different from\nprevious-head.\n"},{"id":"13785","messageId":"Pine.LNX.4.64.0512181215390.26663@localhost.localdomain","threadId":"2858","inReplyTo":"7vd5juub9h.fsf@assigned-by-dhcp.cox.net","subject":"Re: bad git pull","fromName":"Nicolas Pitre","fromEmail":"nico@cam.org","sentAt":"2005-12-18T17:16:02Z","receivedAt":"2005-12-18T17:16:02Z","isPatch":false,"sender":{"key":"nico@fluxnic.net","avatar":"https://avatars.githubusercontent.com/u/702790?v=4"},"body":"On Sat, 17 Dec 2005, Junio C Hamano wrote:\n\n> Nicolas Pitre writes:\n> \n> >> I do not see much difference either way,\n> >\n> > ORIG suggests \"origin\" to me,...\n> \n> Hmph.\n> \n> I always thought it was original-head before the operation\n> happened, which is why I said it is no different from\n> previous-head.\n\nOK I agree.\n\n\nNicolas\n"}]}