Re: git-apply that handles rejects like merge conflicts

From: Ori Avtalion <ori@avtalion.name>
Date: Nov 8, 2011, 20:50 UTC
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