threads / discuss / 21368

Problems with git am

Subject: Problems with git am

## tl;dr

5 messages between Oct 27, 2009 and Oct 27, 2009.

replies: 4people: 3as markdown or json

Alan· Oct 27, 2009, 00:12 UTC · lore

I am encountering an interesting issue. I am not certain if I am doing something wrong or I am encountering a bug or what.

I am using Git version 1.6.0.6 from Fedora 9. I am not using the current version because it has changed how it errors out. (If git does not understand the patch, instead of exiting with an error code that xargs will fail on it exits with something non-fatal.)

I have a number of patches that I have been handed to apply to a git tree.

The patches have been generated by git, but have not been e-mailed. (They may have been extracted from gitweb or some other source.)

The header of the patch looks like:
commit 62b266585bb5555d44a764c90d80f9c4bb8188c1
Author: Joe Example <joe@example.com>
Date:   Wed Sep 19 10:03:47 2009 -0600
There is no e-mail line, but it has the information for e-mail address.
If I apply this patch it will error out with:
"Patch does not have a valid e-mail address."

If I use a current version of Git it errors out with a message "Cannot determine patch format", but does not issue a fatal error code.

If I use git-apply on this patch, it applies it to the tree, but does not commit it. (I need the comments and signoffs to remain intact.) I have to cut-and-paste the commit information to keep it. (I am working on an automated process to handle these patches and don' want to have to reinvent git-am.)

Am i doing something wrong here?

My goal is to be able to take whatever patch I am handed and apply it to the current tree. If it is a raw diff, I can handle that. What concerns me are these patches that look like they are generated by git, but which do not apply cleanly with git-am.

Is there some sort of instructions for applying patches that are dumped out using "git-show" or some other mechanism?

I am not finding this process documented anywhere. (If it is, it is pretty well hidden.)

Thanks!
Junio C Hamano· Oct 27, 2009, 00:52 UTC · re: Alan · lore

Re: Problems with git am

"Alan" <alan@clueserver.org> writes:
Show 5 quoted lines
> The header of the patch looks like:
>
> commit 62b266585bb5555d44a764c90d80f9c4bb8188c1
> Author: Joe Example <joe@example.com>
> Date:   Wed Sep 19 10:03:47 2009 -0600
It shouldn't.

The format "git am" understands is a mbox file and format-patch is the command to write commits out in that form. It should begin with lines that look like:

    From 610f99ec7d22b5750f12350f67c1341d6be8030f Mon Sep 17 00:00:00 2001
    From: Junio C Hamano <gitster@pobox.com>
    Date: Sun, 25 Oct 2009 18:41:09 -0700
    Subject: [PATCH] Update draft release notes to 1.6.6
    Signed-off-by: Junio C Hamano <gitster@pobox.com>
    ---
    .... patch follows here ...

I do not think it is particularly hard to add a new case arm in "am" to support "git log" output. It is different from a mbox format in that it

 * begins each commit with "commit " marker;
 * has Author: and Date: header that is different from a mailbox;
 * lacks Subject: but makes it part of the message body; and
 * indents the message by 4 places.
Nobody has bothered to do so, probably because nobody needed it.

The easiest, safest and quickest for you right now (meaning, before waiting for anybody to help you by adding a new feature to "am") would be to see if it is possible for you to get the commits re-exported in an appropriate format.

I say the "safest" in the above because you _could_ massage what you have into a format that looks like a mbox with some Perl script, but it risks mismassaging.

alan· Oct 27, 2009, 01:43 UTC · re: Junio C Hamano · lore

Re: Problems with git am

On Mon, 26 Oct 2009, Junio C Hamano wrote:
Show 32 quoted lines
> "Alan" <alan@clueserver.org> writes:
>
>> The header of the patch looks like:
>>
>> commit 62b266585bb5555d44a764c90d80f9c4bb8188c1
>> Author: Joe Example <joe@example.com>
>> Date:   Wed Sep 19 10:03:47 2009 -0600
>
> It shouldn't.
>
> The format "git am" understands is a mbox file and format-patch is the
> command to write commits out in that form.  It should begin with lines
> that look like:
>
>    From 610f99ec7d22b5750f12350f67c1341d6be8030f Mon Sep 17 00:00:00 2001
>    From: Junio C Hamano <gitster@pobox.com>
>    Date: Sun, 25 Oct 2009 18:41:09 -0700
>    Subject: [PATCH] Update draft release notes to 1.6.6
>
>    Signed-off-by: Junio C Hamano <gitster@pobox.com>
>    ---
>    .... patch follows here ...
>
> I do not think it is particularly hard to add a new case arm in "am" to
> support "git log" output.  It is different from a mbox format in that it
>
> * begins each commit with "commit " marker;
> * has Author: and Date: header that is different from a mailbox;
> * lacks Subject: but makes it part of the message body; and
> * indents the message by 4 places.
>
> Nobody has bothered to do so, probably because nobody needed it.

[Insert long string of profanity cut and pasted from Linus' description of CVS and Subversion.]

> The easiest, safest and quickest for you right now (meaning, before
> waiting for anybody to help you by adding a new feature to "am") would be
> to see if it is possible for you to get the commits re-exported in an
> appropriate format.

I can get them reexported. I may have problems getting them to do that correctly on a regular basis...

I may have to write the am branch myself.
> I say the "safest" in the above because you _could_ massage what you have
> into a format that looks like a mbox with some Perl script, but it risks
> mismassaging.
Yeah.

The other question is what the proper behaviour when git-am in unable to process a patch. Under git 1.6.0, it exits with a non-zero error code. Under the current git in the git repo it issues and error and exits with a non-error exit code.

What should the correct behaviour be in this case?
-- 
Truth is stranger than fiction because fiction has to make sense.
Junio C Hamano· Oct 27, 2009, 02:31 UTC · re: alan · lore

Re: Problems with git am

alan <alan@clueserver.org> writes:
> The other question is what the proper behaviour when git-am in unable
> to process a patch.  Under git 1.6.0, it exits with a non-zero error
> code. Under the current git in the git repo it issues and error and
> exits with a non-error exit code.

Hmph, that sounds like a recent regression to me. I'll try to find time to look into it myself sometime tonight but no promises.

Jeff King· Oct 27, 2009, 19:02 UTC · re: Junio C Hamano · lore

Re: Problems with git am

On Mon, Oct 26, 2009 at 07:31:34PM -0700, Junio C Hamano wrote:
Show 9 quoted lines
> alan <alan@clueserver.org> writes:
> 
> > The other question is what the proper behaviour when git-am in unable
> > to process a patch.  Under git 1.6.0, it exits with a non-zero error
> > code. Under the current git in the git repo it issues and error and
> > exits with a non-error exit code.
> 
> Hmph, that sounds like a recent regression to me.  I'll try to find time
> to look into it myself sometime tonight but no promises.

I'm having trouble reproducing, either with a totally bogus input format or with "git log -p" output (which is what it sounds like the OP has). Both of these tests already pass on 'next':

diff --git a/t/t4150-am.sh b/t/t4150-am.sh
index 8296605..2d5e32a 100755
--- a/t/t4150-am.sh
+++ b/t/t4150-am.sh
@@ -346,4 +346,17 @@ test_expect_success 'am -q is quiet' '
 	! test -s output.out
 '
 
+test_expect_success 'am properly reports error' '
+	echo excellent > bogus &&
+	test_must_fail git am bogus
+'
+
+test_expect_success 'am properly reports error (git log output)' '
+	echo more content >>file &&
+	git commit -m content file &&
+	git log -1 -p > bogus &&
+	git reset --hard HEAD^ &&
+	test_must_fail git am bogus
+'
+
 test_done

← back to recent threads