{"thread":{"id":"17217","subject":"git add --patch bug with split+edit?","startedAt":"2009-01-17T01:37:43Z","lastAt":"2009-01-17T02:33:46Z","messageCount":2,"participants":["Hannu Koivisto","Jeff King"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"100785","messageId":"833afihfvc.fsf@kalahari.s2.org","threadId":"17217","inReplyTo":null,"subject":"git add --patch bug with split+edit?","fromName":"Hannu Koivisto","fromEmail":"azure@iki.fi","sentAt":"2009-01-17T01:37:43Z","receivedAt":"2009-01-17T01:37:43Z","isPatch":false,"sender":{"key":"azure@iki.fi","avatar":null},"body":"Greetings,\n\nIf I have a hunk that adds three lines, I can edit the hunk and\nremove the last line but I can't split it in two, stage the first\npart, edit the second part and remove the last line.  An example:\n\nmkdir gittest\ncd gittest\ngit init\necho \"baz\\nbaz\" > baz\ngit add baz\ngit commit -m baz baz\nrm baz\necho \"sur\\nbaz\\nbaz\\njee\\njee\" > baz\ngit add --patch\n\nNow say 's RET y RET e RET' and remove the second \"+jee\" line using\nyour editor.  The output for me looks like this:\n\n--8<-----------------------------------------------------------------\ndiff --git a/baz b/baz\nindex 1f55335..48a5f83 100644\n--- a/baz\n+++ b/baz\n@@ -1,2 +1,5 @@\n+sur\n baz\n baz\n+jee\n+jee\nStage this hunk [y/n/a/d/s/e/?]? s\nSplit into 2 hunks.\n@@ -1,2 +1,3 @@\n+sur\n baz\n baz\nStage this hunk [y/n/a/d/j/J/e/?]? y\n@@ -1,2 +2,4 @@\n baz\n baz\n+jee\n+jee\nStage this hunk [y/n/a/d/K/e/?]? e\nWaiting for Emacs...\nerror: patch failed: baz:1\nerror: baz: patch does not apply\nYour edited hunk does not apply. Edit again (saying \"no\" discards!) [y/n]?\n--8<-----------------------------------------------------------------\n\nWhat I also didn't expect is that if I answer 'n' to that last\nquestion, I get...\n\n@@ -1,2 +1,3 @@\n+sur\n baz\n baz\nStage this hunk [y/n/a/d/j/J/e/?]?\n\n...which is the first part of the splitted hunk that I already\nstaged.  If I answer 'd', git status and git diff indicate that\n\"+sur\" is nevertheless staged.\n\nNow, if instead of splitting the hunk and editing it, I edit the\nentire...\n\n@@ -1,2 +1,5 @@\n+sur\n baz\n baz\n+jee\n+jee\n\n...hunk and remove the last \"+jee\" line, I get no error.\n\nI'm using git 1.6.1 on Linux.\n\n-- \nHannu\n"},{"id":"100787","messageId":"20090117023346.GA15817@coredump.intra.peff.net","threadId":"17217","inReplyTo":"833afihfvc.fsf@kalahari.s2.org","subject":"Re: git add --patch bug with split+edit?","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2009-01-17T02:33:46Z","receivedAt":"2009-01-17T02:33:46Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Sat, Jan 17, 2009 at 03:37:43AM +0200, Hannu Koivisto wrote:\n\n> echo \"sur\\nbaz\\nbaz\\njee\\njee\" > baz\n> git add --patch\n> \n> Now say 's RET y RET e RET' and remove the second \"+jee\" line using\n> your editor.  The output for me looks like this:\n> [...]\n> error: patch failed: baz:1\n> error: baz: patch does not apply\n> Your edited hunk does not apply. Edit again (saying \"no\" discards!) [y/n]?\n\nActually, you do not even need to change the patch at all for this to\nfail. The hunk that you edit looks like this:\n\n@@ -1,2 +2,4 @@\n baz\n baz\n+jee\n+jee\n\nwhich doesn't make sense. I think the hunk header should actually be:\n\n  @@ -1,2 +1,4 @@\n\nBut I don't think that is the problem, since git-apply should be\nrecounting the hunk information (and in a simple test, it doesn't fix\nit).\n\nHm. OK, I see. The \"does this diff apply\" check feeds _both_ parts of\nthe split patch to git-apply. But of course the second part will never\ncorrectly apply, because its context overlaps with the first part, but\ndoesn't take it into account.\n\nDoing the check with _just_ the edited patch would work. But that\ndoesn't take into account that your edited patch will potentially fail\nto apply in the long run, depending on whether or not you accept the\nother half of the split patch. And we can't know that yet, because the\nuser may not have told us (they could have skipped the first half, and\nthen come back to it later after the edit step).\n\nSo in general, I think splitting and editing the same hunk is inherently\ndangerous and is going to lead to these sorts of problems. And because\nediting provides a superset of the functionality, I think you should\njust edit and either allow the first part of the hunk to be applied or\nnot depending on your preference.\n\nBut maybe there is some better way of resolving the conflict. I don't\nsee one, but I'm tired and didn't think too hard on it. :)\n\n-Peff\n"}]}