Thread (4 messages) 4 messages, 3 authors, 2016-06-15

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
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help