Re: [PATCH] git-am: indicate where a failed patch is to be found.

From: Paul Gortmaker <paul.gortmaker@windriver.com>
Date: Jul 12, 2012, 19:36 UTC
Message-ID: <4FFF2720.6090705@windriver.com>
In-Reply-To: <7va9z4byl3.fsf@alter.siamese.dyndns.org>

On 12-07-12 02:53 PM, Junio C Hamano wrote:

Show 26 quoted lines

> Paul Gortmaker <paul.gortmaker@windriver.com> writes:
> 
>> On 12-07-12 01:45 PM, Junio C Hamano wrote:
>>> Paul Gortmaker <paul.gortmaker@windriver.com> writes:
>>>
>>>> If git am wasn't run with --reject, we assume the end user
>>>> knows where to find the patch.  This is normally true for
>>>> a single patch,
>>>
>>> Not at all.  Whether it is a single or broken, the patch is fed to
>>> underlying "apply" from an unadvertised place.
>>
>> What I meant by this was the difference between:
>>
>> 	git am 0001-some-standalone-single.patch
>> vs.
>> 	git am mbox
>>
>> In the 1st, the standalone patch is 100% clear and easy to access,
>> because we really don't need/care about the unadvertised place.
> 
> It does not matter at all that 0001-foo.patch only has a single
> patch.  If you are going to fix up the patch after you saw "git am"
> failed, you will be fixing .git/rebase-apply/patch with your editor
> and re-run "git am" without arguments, at which point "git am" will
> not look at your 0001-foo.patch file at all.

I think this is where our two thinking paths diverge. You are suggesting I edit and fix the patch. Yes, occasionally I do that, if it is a trivial context change. But hand editing a patch is not for Joe Average, and gets very complicated in all but the trivial cases. So, what happens _way_ more often, is that I want to apply what can be applied, and deal with the rejects on a one-by-one basis after that. (BTW, this is not just me; this patch came about from discussions with other kernel folks.)

Show 10 quoted lines

> 
>>> This is _NOT_ fine, especially if you suggest "patch" the user may
>>> not have, and more importantly does not have a clue why "git apply"
>>> rejected it ("am" does _not_ use "patch" at all).
>>
>> I'm not 100% sure I'm following what part here is not OK.  If you
>> can help me understand that, I'll respin the change accordingly.
> 
> Do not ever mention "patch -p1".  It is not the command that "git
> am" uses, and it is not what detected the breakage in the patch.

This may be true, but it _is_ the command that I (and others) have defaulted to using, if for no other reason than ignorance.

> 
> The command to guide the user to is "git apply".
>

OK. But I don't see a "--dry-run" equivalent -- and "git apply --check" just gives me a repeat of the same fail messages that "git am" did.

With "patch -p1 --dry-run" I get information that immediately lets me see whether the patch is viable or not. Is there a way to get a similar thing from "git apply" that I've overlooked?

Paul. ---