On Thu, 14 Aug 2008, Stephan Beyer wrote:
quoted text
> 
> 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.

quoted text
> 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@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html