{"thread":{"id":"34045","subject":"git stash while pending merge should not be allowed","startedAt":"2013-06-07T06:52:33Z","lastAt":"2013-06-14T08:30:19Z","messageCount":4,"participants":["Scott McPeak","Junio C Hamano","John Keeping"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"219610","messageId":"51B18331.6060302@coverity.com","threadId":"34045","inReplyTo":null,"subject":"git stash while pending merge should not be allowed","fromName":"Scott McPeak","fromEmail":"smcpeak@coverity.com","sentAt":"2013-06-07T06:52:33Z","receivedAt":"2013-06-07T06:52:33Z","isPatch":false,"sender":{"key":"smcpeak@coverity.com","avatar":null},"body":"A colleague of mine who is well-intentioned and fairly knowledgeable\nabout git recently caused havoc with our repository while merging\nchanges on the main line branch into a feature branch.  The reason is\nthat, along the way, he tried to use \"git stash\" while the merge was\npending.  A few commands later, this severely polluted the history of\nall the files involved.\n\nThe command sequence started as follows:\n\n   $ git checkout feature-branch\n   $ git merge mainline-branch\n   (conflicts; merge pending)\n   $ git mergetool\n   (resolve all conflicts; takes a while as there are many)\n   $ make && make testsuite\n   (oops, tests don't pass)\n\nAt this point, the user notices that the fix to the tests is in the\nnext commit on mainline-branch, which wasn't present when it was first\nmerged.  Not wanting to have a commit in the history whose tests do\nnot pass, and not wanting to redo all the conflict resolution work\ninvolved in starting over with a different merge parent, he tries to\ncherry pick it:\n\n   $ git fetch\n   $ git cherry-pick commit-with-fix\n   (error: can't cherry pick while merge pending)\n\nOk, he thinks, git stash has worked in the past as a way to temporarily\nmove aside some work in progress.  So:\n\n   $ git stash\n   $ git cherry-pick commit-with-fix\n   $ git stash pop\n\nAll seems well, so:\n\n   $ git commit\n\nUnfortunately, this does *not* do what was intended.  You see,\nunbeknownst to this developer, git stash does not save the MERGE_HEAD!\nSo the commit shows up as an enormous single-parent commit on top of\nfeature-branch, referring to none of the merged commits from\nmainline-branch in its ancestry.  Consequently, \"git annotate\" and\nfriends regard all the merged changes as having been made by the\ndeveloper alone and all at once, distorting the file histories to the\npoint of being nearly useless.  Furthermore, git still doesn't think\nmainline-branch has been merged, so there is more fun to be had\nsorting that out when the next merge from mainline happens.\n\nWe are now in the middle of an expensive and risky project to repair\nthe damage, since people pulled and pushed afterward, before the\nproblem was noticed.\n\nI suggest that this problem could easily have been avoided if \"git\nstash\" refused to run with a pending merge (present MERGE_HEAD file),\nsince this is crucial repository state that it does not save.  This\nseems similar to what \"git cherry-pick\" does.\n\n-Scott\n"},{"id":"219667","messageId":"7v1u8du5as.fsf@alter.siamese.dyndns.org","threadId":"34045","inReplyTo":"51B18331.6060302@coverity.com","subject":"Re: git stash while pending merge should not be allowed","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2013-06-07T18:47:07Z","receivedAt":"2013-06-07T18:47:07Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Scott McPeak <smcpeak@coverity.com> writes:\n\n> I suggest that this problem could easily have been avoided if \"git\n> stash\" refused to run with a pending merge (present MERGE_HEAD file),\n> since this is crucial repository state that it does not save.  This\n> seems similar to what \"git cherry-pick\" does.\n\nSounds senslbe.  What do we want to see happen in other states, in\nwhich Git gives control back to the user asking for help before\nmoving forward (e.g. am, rebase, cherry-pick, revert)?\n"},{"id":"220777","messageId":"51BA5CD9.7060007@coverity.com","threadId":"34045","inReplyTo":"7v1u8du5as.fsf@alter.siamese.dyndns.org","subject":"Re: git stash while pending merge should not be allowed","fromName":"Scott McPeak","fromEmail":"smcpeak@coverity.com","sentAt":"2013-06-13T23:59:21Z","receivedAt":"2013-06-13T23:59:21Z","isPatch":false,"sender":{"key":"smcpeak@coverity.com","avatar":null},"body":"On 06/07/13 11:47, Junio C Hamano wrote:\n> Scott McPeak <smcpeak@coverity.com> writes:\n>\n>> I suggest that this problem could easily have been avoided if \"git\n>> stash\" refused to run with a pending merge (present MERGE_HEAD file),\n>> since this is crucial repository state that it does not save.  This\n>> seems similar to what \"git cherry-pick\" does.\n>\n> Sounds senslbe.  What do we want to see happen in other states, in\n> which Git gives control back to the user asking for help before\n> moving forward (e.g. am, rebase, cherry-pick, revert)?\n\nIf you're asking me, I don't know.  My first thought is if there is any \npending state that \"stash\" doesn't save, stash should refuse to run. \nBut I don't know know very much about some of those commands.\n\n-Scott\n"},{"id":"220788","messageId":"20130614083018.GD23890@serenity.lan","threadId":"34045","inReplyTo":"7v1u8du5as.fsf@alter.siamese.dyndns.org","subject":"Re: git stash while pending merge should not be allowed","fromName":"John Keeping","fromEmail":"john@keeping.me.uk","sentAt":"2013-06-14T08:30:19Z","receivedAt":"2013-06-14T08:30:19Z","isPatch":false,"sender":{"key":"john@keeping.me.uk","avatar":"https://avatars.githubusercontent.com/u/1702081?v=4"},"body":"On Fri, Jun 07, 2013 at 11:47:07AM -0700, Junio C Hamano wrote:\n> Scott McPeak <smcpeak@coverity.com> writes:\n> \n> > I suggest that this problem could easily have been avoided if \"git\n> > stash\" refused to run with a pending merge (present MERGE_HEAD file),\n> > since this is crucial repository state that it does not save.  This\n> > seems similar to what \"git cherry-pick\" does.\n> \n> Sounds senslbe.  What do we want to see happen in other states, in\n> which Git gives control back to the user asking for help before\n> moving forward (e.g. am, rebase, cherry-pick, revert)?\n\nI don't think there's any need to prevent stash running in these cases\nand I sometimes find it useful that I can stash during a rebase.\n\nHaving said that, I wonder what happens with \"cherry-pick -x\" if you do\nstash changes while it is stopped.  I don't think that is as serious as\nthe merge case because it's easy to detect in the commit message.\n"}]}