On Thu, 14 Aug 2008, Stephan Beyer wrote: > > What I missed when I first used git-apply (git-am) with some not-so- > well-done patches was something like a "simulated merge" (of course, > only when you ask for it), i.e. something like a user-friendly > --reject behavior: It's really hard to do. Largely impossible, I think. The reason is that when a patch fails, you - by definition - don't really know where it is supposed to apply and what the original code is. Because if you did, the patch wouldn't fail! Git *can* do it (git am -3, as people have said), when you have a git patch, and the patch indicates the original blob. Then git can just see what the original state was, reconstruct the patched file, and do a normal three-way merge. But it's not doable in general. Now, we could do other things, like try to _search_ for an original blob that it applies cleanly to (or even have a "guessing mode" that does a really rough patch-application with the GNU patch defaults and then does a three-way merge of a fudged version with no fuzz as the base), so I'm not saying that it would be fundamentally impossible to try to go further than what we do now, but it's definitely not trivial to do. > Instead of generating reject files it puts conflict markers into the file. > (If no context matches at all, then perhaps just insert them at the lines > that the hunk header says.) > And then declaring the files as "unmerged", so that you can see it in > git status. I do agree that it would be very cool. I'm so used to editing patches to match the target files by hand that I don't personally mind. I absolutely detest reject files personally because of the way they mean that you have a half-way done thing, so I will literally always edit the original patch in place instead. But I agree that what you describe would be absolutely lovely. Linus -- 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
