On 2015-07-30 12:35 AM, Jacob Keller wrote:
> On Wed, Jul 29, 2015 at 3:20 PM, Stefan Beller wrote:
>> On Wed, Jul 29, 2015 at 3:01 PM, Paul Gortmaker
>> wrote:
>>> The linux kernel repository has some commits in it with dates from
>>> the year 1970 and als
~/git/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
---
git-am
On 13-08-20 03:54 PM, Steven Rostedt wrote:
> On Tue, 20 Aug 2013 12:45:03 -0700
> Junio C Hamano wrote:
>
>> Steven Rostedt 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 told me that "
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 equiva
On 13-08-20 01:57 PM, Junio C Hamano wrote:
> Paul Gortmaker 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 po
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 ap
other reason, than to simplifly the
parsing of what the makefile is trying to do by humans.
Signed-off-by: Paul Gortmaker
diff --git a/Makefile b/Makefile
index 9bc5e40..56f55f6 100644
--- a/Makefile
+++ b/Makefile
@@ -1573,8 +1573,8 @@ else
REMOTE_CURL_NAMES = $(REMOTE_CURL_PRIMARY)
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
diff --git a/builtin/apply.c b/builtin/apply.c
index d453c83..3bf71dc 100644
--- a/builtin/apply.c
+++ b/builtin/apply.c
@@ -188,7 +
On 12-08-02 05:20 PM, Junio C Hamano wrote:
> Paul Gortmaker 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 de
ntelligently and automatically on these with "git apply".
If we can unambiguously map what was recorded as the deleted
SHA prefix to the SHA of the matching blob filename in our tree,
then we set the image len to zero which facilitates the delete.
Signed-off-by: Paul Gortmaker
---
For a r
On 12-08-01 02:48 PM, Junio C Hamano wrote:
> Paul Gortmaker 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:
>>
>&g
e.g. linux 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
---
See http://lkml.i
On 12-07-25 05:52 PM, Junio C Hamano wrote:
> Paul Gortmaker 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.
--
>
> built
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 commit
On 12-07-13 03:58 PM, Junio C Hamano wrote:
> Paul Gortmaker 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
>> man
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"
>>>>>
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
---
[v2: drop text suggesting what to do with failed patch; only
emit the help text if we are processing mbox with multi patches]
git-am.sh |5 +
1 file
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 fin
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 si
d the patch to do the manual fixup before eventually
continuing with "git add ... ; git am -r".
Signed-off-by: Paul Gortmaker
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'
20 matches
Mail list logo
