On Sat, Jan 17, 2009 at 03:37:43AM +0200, Hannu Koivisto wrote: > echo "sur\nbaz\nbaz\njee\njee" > baz > git add --patch > > Now say 's RET y RET e RET' and remove the second "+jee" line using > your editor. The output for me looks like this: > [...] > error: patch failed: baz:1 > error: baz: patch does not apply > Your edited hunk does not apply. Edit again (saying "no" discards!) [y/n]? Actually, you do not even need to change the patch at all for this to fail. The hunk that you edit looks like this: @@ -1,2 +2,4 @@ baz baz +jee +jee which doesn't make sense. I think the hunk header should actually be: @@ -1,2 +1,4 @@ But I don't think that is the problem, since git-apply should be recounting the hunk information (and in a simple test, it doesn't fix it). Hm. OK, I see. The "does this diff apply" check feeds _both_ parts of the split patch to git-apply. But of course the second part will never correctly apply, because its context overlaps with the first part, but doesn't take it into account. Doing the check with _just_ the edited patch would work. But that doesn't take into account that your edited patch will potentially fail to apply in the long run, depending on whether or not you accept the other half of the split patch. And we can't know that yet, because the user may not have told us (they could have skipped the first half, and then come back to it later after the edit step). So in general, I think splitting and editing the same hunk is inherently dangerous and is going to lead to these sorts of problems. And because editing provides a superset of the functionality, I think you should just edit and either allow the first part of the hunk to be applied or not depending on your preference. But maybe there is some better way of resolving the conflict. I don't see one, but I'm tired and didn't think too hard on it. :) -Peff -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
