Re: git-apply that handles rejects like merge conflicts
From: Jeff King <hidden>
Date: 2016-06-15 22:52:26
On Mon, Nov 07, 2011 at 03:45:48PM -0800, Junio C Hamano wrote:
Jeff King [off-list ref] writes:quoted
In the general case, you can't represent all failed hunks with conflict markers, can you?Conflict markers come from the use of a 3-way merge, and if you were to do a 3-way merge, by definition, you would need some way to tell where the preimage of the patch and the target tree you are attempting to apply the patch forked from. That's done by fall-back-3way in "am -3". You _could_ lift that logic out of "am -3", but I do not think it is worth the effort to do so (IOW, I do not see a reason to avoid "am -3").
I think it would purely be "I have a patch produced by git diff, not by
git format-patch". If you want to use "am -3", you would have to dress
up your patch with mail headers.
In practice, this doesn't come up much for me. I think I was using "git
diff >patch" as a poor-man's stash (and I did just stick some fake
headers in, and "git reset HEAD^" afterwards). But maybe other workflows
deal with this more.
But I think there are two questions:
1. Should am's 3-way fallback be made more easily available to users
of regular "apply"?
2. Short of doing a 3-way merge, are there better ways to represent
failed hunks in the patch target itself, rather than saving ".rej"
files?
I'm actually not sure which one Ori was asking about.
-Peff