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

2012-07-13 Thread Junio C Hamano
Paul Gortmaker 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

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

2012-07-13 Thread Paul Gortmaker
On 12-07-12 04:00 PM, Junio C Hamano wrote: > Paul Gortmaker writes: > > 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%

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

2012-07-12 Thread Junio C Hamano
Paul Gortmaker writes: > 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

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

2012-07-12 Thread Jeff King
On Thu, Jul 12, 2012 at 02:32:01PM -0400, Paul Gortmaker wrote: > In case it helps any, a brief summary of my workflow is this: > > git am /tmp/mbox > > patch -p1 --dry-run < .git/rebase-apply/patch > # gauge status. Is patch really invalid, or already applied? > # already applied; "git am --sk

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

2012-07-12 Thread Junio C Hamano
Paul Gortmaker writes: 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

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

2012-07-12 Thread Paul Gortmaker
On 12-07-12 02:53 PM, Junio C Hamano wrote: > Paul Gortmaker writes: > >> On 12-07-12 01:45 PM, Junio C Hamano wrote: >>> Paul Gortmaker 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,

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

2012-07-12 Thread Junio C Hamano
Paul Gortmaker writes: > On 12-07-12 01:45 PM, Junio C Hamano wrote: >> Paul Gortmaker 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

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

2012-07-12 Thread Paul Gortmaker
On 12-07-12 01:45 PM, Junio C Hamano wrote: > Paul Gortmaker 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

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

2012-07-12 Thread Junio C Hamano
Paul Gortmaker 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. > So, provide a hel

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

2012-07-12 Thread Paul Gortmaker
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, but if the user is processing a mbox with many patches, they may not have a single broken out patch handy. So, provide a helpful hint as to where they can find the p