From: Ori Avtalion <ori@avtalion.name>
Date: Tue, 08 Nov 2011 20:50:51 GMT
Subject: Re: git-apply that handles rejects like merge conflicts
Message-ID: <4EB9962B.8060809@avtalion.name>
In-Reply-To: <20111108054643.GC29643@sigill.intra.peff.net>

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>

>>   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