Re: git-apply that handles rejects like merge conflicts

On 11/08/2011 07:46 AM, Jeff King wrote:

On Mon, Nov 07, 2011 at 03:45:48PM -0800, Junio C Hamano wrote:
But I think there are two questions:

[ snip ]

I'm actually not sure which one Ori was asking about.

I'm actually interested in both :)

Here's a copy of the description of my problem from another reply:

I'm dealing with two codebases that have branched in the past, before
any VCS was used, and now I'm tracking both separately with git. I'm
trying to  apply changes from one to the other with format-patch and
git-am/apply.

In answer to your first question

  1. Should am's 3-way fallback be made more easily available to users
     of regular "apply"?

git-am is never part of this workflow as I'm trying to move patches
between separate repositories with no shared root.

<rant>
And, personally, I don't think git-am is named correctly as the only
use-case I have for it is applying+committing single patches produced by
format-patch and sent as individual files over some medium which isn't
mboxes (I'm not that old-school). I never understood why git-apply can't
do the commit and I have to instead use a tool with 'mail' in its name
(Let's ignore the historical reasons) -- Shouldn't git-am be an
mbox-reading wrapper around some more basic patch-applying tool?
</rant>

quoted

  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 really want this as .rej files feel very un-git-like. However, after
understanding the problems raised in this thread, I'm a bit more
realistic :)

-Ori