Paul Gortmaker <paul.gortma...@windriver.com> 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 ;-). -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
