Should git apply --check imply verbose?

2013-08-20 Thread Paul Gortmaker
TL;DR -- git apply --reject implies verbose, but the similar git apply --check does not, which seems inconsistent. Background: A common (non-git) workflow can be to use patch --dry-run to inspect whether a patch is feasible, and then use patch again a 2nd time (w/o --dry-run) to actually apply

Re: Should git apply --check imply verbose?

2013-08-20 Thread Paul Gortmaker
On 13-08-20 01:57 PM, Junio C Hamano wrote: Paul Gortmaker paul.gortma...@windriver.com writes: TL;DR -- git apply --reject implies verbose, but the similar git apply --check does not, which seems inconsistent. Hmmm, I am of two minds. From purely idealistic point of view, I can see why

Re: Should git apply --check imply verbose?

2013-08-20 Thread Paul Gortmaker
On 13-08-20 02:51 PM, Jonathan Nieder wrote: Hi Paul, Paul Gortmaker wrote: OK, so given your feedback, how do you feel about a patch to the documentation that indicates to use -v in combination with the --check to get equivalent patch --dry-run behaviour? Sounds like a good idea to me

Re: Should git apply --check imply verbose?

2013-08-20 Thread Paul Gortmaker
On 13-08-20 03:54 PM, Steven Rostedt wrote: On Tue, 20 Aug 2013 12:45:03 -0700 Junio C Hamano gits...@pobox.com wrote: Steven Rostedt rost...@goodmis.org writes: I do not think it is necessarily a good idea to assume that people who are learning git apply know how GNU patch works. Linus

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

2012-07-12 Thread Paul Gortmaker
the patch to do the manual fixup before eventually continuing with git add ... ; git am -r. Signed-off-by: Paul Gortmaker paul.gortma...@windriver.com diff --git a/git-am.sh b/git-am.sh index f8b7a0c..32e6ac0 100755 --- a/git-am.sh +++ b/git-am.sh @@ -854,7 +854,10 @@ did you forget to use 'git add

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 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

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 paul.gortma...@windriver.com writes: 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

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

2012-07-13 Thread Paul Gortmaker
the patch to do some sort of manual fixup, if we are processing a mbox with more than one patch in it. Signed-off-by: Paul Gortmaker paul.gortma...@windriver.com --- [v2: drop text suggesting what to do with failed patch; only emit the help text if we are processing mbox with multi patches] git

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

2012-07-13 Thread Paul Gortmaker
On 12-07-13 03:58 PM, Junio C Hamano wrote: Paul Gortmaker paul.gortma...@windriver.com writes: If git am fails to apply something, the end user may need to know where to find the patch. This is normally known for a single patch, but if the user is processing a mbox with many patches

False positive from orphaned_commit_warning() ?

2012-07-25 Thread Paul Gortmaker
Has anyone else noticed false positives coming from the orphan check? It is warning me about commits that are clearly on master. Here is an example, where I checkout master~2 and then switch back to master. It somehow thinks that master~2 is orphaned, when master~2 is by definition in the

Re: False positive from orphaned_commit_warning() ?

2012-07-26 Thread Paul Gortmaker
On 12-07-25 05:52 PM, Junio C Hamano wrote: Paul Gortmaker paul.gortma...@windriver.com writes: Has anyone else noticed false positives coming from the orphan check? Thanks. This should fix it. Indeed it does. Thanks for the fix (and git in general). Paul. -- builtin/checkout.c

[PATCH] git-am: make a config setting for --keep-non-patch switch

2012-08-01 Thread Paul Gortmaker
kernel stable trees) to have the subjects remain invariant during a backport, there is a genuine need for making this the default behaviour from a config file, versus specifying it in scripts and on the command line each time. Signed-off-by: Paul Gortmaker paul.gortma...@windriver.com --- See http

Re: [PATCH] git-am: make a config setting for --keep-non-patch switch

2012-08-01 Thread Paul Gortmaker
On 12-08-01 02:48 PM, Junio C Hamano wrote: Paul Gortmaker paul.gortma...@windriver.com writes: In order to make a commit be invariant (excluding ID) over a format-patch and subsequent am cycle, one needs to use the '--keep-non-patch' so that commits like: [PATCH] [i386] fix foo bar

Re: [RFC/PATCH] apply: parse and act on --irreversible-delete output

2012-08-02 Thread Paul Gortmaker
On 12-08-02 05:20 PM, Junio C Hamano wrote: Paul Gortmaker paul.gortma...@windriver.com writes: The '-D' or '--irreversible-delete' option of format-patch is great for sending out patches to mailing lists, where there is little value in seeing thousands of lines of deleted code. Attention

[PATCH] apply: delete unused deflate_origlen from patch struct

2012-08-02 Thread Paul Gortmaker
It hasn't been used since 2006, as of commit 3cd4f5e8 git-apply --binary: clean up and prepare for --reverse Signed-off-by: Paul Gortmaker paul.gortma...@windriver.com diff --git a/builtin/apply.c b/builtin/apply.c index d453c83..3bf71dc 100644 --- a/builtin/apply.c +++ b/builtin/apply.c

[PATCH] git-am: flag suspiciously old or futuristic commits

2015-07-29 Thread Paul Gortmaker
/linux-head$ git reset --hard HEAD~ /dev/null paul@builder:~/git/linux-head$ git am past.patch note: commit is from implausibly old year 1977. Applying: arch/sh: make heartbeat driver explicitly non-modular paul@builder:~/git/linux-head$ Signed-off-by: Paul Gortmaker paul.gortma...@windriver.com

Re: [PATCH] git-am: flag suspiciously old or futuristic commits

2015-07-30 Thread Paul Gortmaker
On 2015-07-30 12:35 AM, Jacob Keller wrote: On Wed, Jul 29, 2015 at 3:20 PM, Stefan Beller sbel...@google.com wrote: On Wed, Jul 29, 2015 at 3:01 PM, Paul Gortmaker paul.gortma...@windriver.com wrote: The linux kernel repository has some commits in it with dates from the year 1970 and also