From: Paul Gortmaker <paul.gortmaker@windriver.com>
To: Junio C Hamano <gitster@pobox.com>
Cc: <git@vger.kernel.org>
Subject: Re: [PATCH] git-am: indicate where a failed patch is to be found.
Date: Thu, 12 Jul 2012 14:32:01 -0400 [thread overview]
Message-ID: <4FFF1821.7030705@windriver.com> (raw)
In-Reply-To: <7vhatcc1ql.fsf@alter.siamese.dyndns.org>
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.
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.
--
>
>
next prev parent reply other threads:[~2012-07-12 18:32 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-07-12 15:50 [PATCH] git-am: indicate where a failed patch is to be found Paul Gortmaker
2012-07-12 17:45 ` Junio C Hamano
2012-07-12 18:32 ` Paul Gortmaker [this message]
2012-07-12 18:53 ` Junio C Hamano
2012-07-12 19:36 ` Paul Gortmaker
2012-07-12 20:00 ` Junio C Hamano
2012-07-13 17:40 ` Paul Gortmaker
2012-07-13 18:06 ` Junio C Hamano
2012-07-12 21:07 ` Junio C Hamano
2012-07-13 15:51 ` [PATCH v2] " Paul Gortmaker
2012-07-13 19:58 ` Junio C Hamano
2012-07-13 22:46 ` Paul Gortmaker
2012-07-13 23:02 ` Junio C Hamano
2012-07-12 21:18 ` [PATCH] " Nicolas Sebrecht
2012-07-12 21:55 ` Junio C Hamano
2012-07-12 20:33 ` [PATCH] " Jeff King
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4FFF1821.7030705@windriver.com \
--to=paul.gortmaker@windriver.com \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).