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

Paul Gortmaker [off-list ref] writes:

Sorry, that description was a bit context free.  Two typical cases:

1) applying a series of commits (e.g. preempt RT feature) to a newer
baseline. Some of those commits may have been upstreamed and now
present in mainline.  The "git am" failure doesn't really hint that
"already applied" may be the case -- e.g. consider and compare the
output when we extract and then intentionally try to re-apply something
already in tree, created with:

-------------
$git format-patch 50fb31cf~..50fb31cf
0001-tty-hvc_opal-Fix-debug-function-name.patch
-------------

With "git am":
--------------------------
$git am 0001-tty-hvc_opal-Fix-debug-function-name.patch
Applying: tty/hvc_opal: Fix debug function name
error: patch failed: drivers/tty/hvc/hvc_opal.c:401
error: drivers/tty/hvc/hvc_opal.c: patch does not apply
Patch failed at 0001 tty/hvc_opal: Fix debug function name
When you have resolved this problem run "git am --resolved".
If you would prefer to skip this patch, instead run "git am --skip".
To restore the original branch and stop patching run "git am --abort".
---------------------------

...versus 

---------------------------
$patch -p1 --dry-run < 0001-tty-hvc_opal-Fix-debug-function-name.patch 
patching file drivers/tty/hvc/hvc_opal.c
Reversed (or previously applied) patch detected!  Assume -R? [n] 
Apply anyway? [n] 
Skipping patch.
1 out of 1 hunk ignored -- saving rejects to file drivers/tty/hvc/hvc_opal.c.rej
---------------------------

"git am -3" will give you a message "already applied" and moves on,
or if an already applied stuff is similar but not different would
stop with conflict, or fail butd the latter two cases GNU patch
would not say "reversed", so "am -3" would be a win 2 out of 3 cases
and the remaining 1 out of 3 case would be a tie.

2) In maintaining linux stable releases (esp older ones), the dry-run
output, if say it says something like 23/30 chunks failed, it tells me
that the underlying baseline has probably changed too much for a simple
backport.  But if only 1/30 chunks fail or similar, I'll simply proceed
since the backport is viable and likely trivial.

Perhaps "git apply" when stops upon unapplicable patch may want to
be improved to give more detailed diagnostics (I think it stops upon
first hunk per each file that is touched---it may be able to keep
going and see if other hunks might apply).  This is in "patches
welcome" category ;-).