On 12-07-12 01:45 PM, Junio C Hamano wrote:
> Paul Gortmaker <paul.gortma...@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.
Maybe I should have said "knows how to get at the single patch"?
>
>> So, provide a helpful hint as to where they can
>> find the patch ...
>
> This is OK, but you may want to give a way to squelch it once the
> user learns where it is by following the usual "advice.*" thing.
>
>> ... to do the manual fixup before eventually
>> continuing with "git add ... ; git am -r".
>
> 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.
Is it the assumption that the user will have the patch
command in /usr/bin not OK, or that the message implies that
git is somehow using /usr/bin/patch is not OK?
In case it helps any, a brief summary of my workflow is this:
git am /tmp/mbox
<some random fail halfway in the queue>
patch -p1 --dry-run < .git/rebase-apply/patch
# gauge status. Is patch really invalid, or already applied?
# already applied; "git am --skip"
# no, if valid, but with minor issues, apply what we can.
patch -p1 < .git/rebase-apply/patch
# manually deal with rejects (typically with wiggle)
git add any_new_files
git add -u
git am -r
Paul.
--
>
>
--
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
