Re: git-apply that handles rejects like merge conflicts

From: Jeff King <peff@peff.net>
Date: Nov 8, 2011, 05:46 UTC
Message-ID: <20111108054643.GC29643@sigill.intra.peff.net>
In-Reply-To: <7v4nyf1opf.fsf@alter.siamese.dyndns.org>

On Mon, Nov 07, 2011 at 03:45:48PM -0800, Junio C Hamano wrote:

Show 12 quoted lines

> Jeff King <peff@peff.net> writes:
> 
> > 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