[PATCH] cherry-pick -x: improve handling of one-liner commit messages

[PATCH] cherry-pick -x: improve handling of one-liner commit messages

[Miklos Vajna]

git cherry-pick -x normally just appends the "cherry picked from commit"
line at the end of the message, which is fine. However, in case the
original commit message had only one line, first append a newline,
otherwise the second line won't be empty, which is against
recommendations.
---
 sequencer.c                   | 10 ++++++++++
 t/t3501-revert-cherry-pick.sh |  8 ++++++++
 2 files changed, 18 insertions(+)

diff --git a/sequencer.c b/sequencer.c
index aef5e8a..1ae0e43 100644
--- a/sequencer.c
+++ b/sequencer.c
@@ -496,6 +496,16 @@ static int do_pick_commit(struct commit *commit, struct replay_opts *opts)
 		}
 
 		if (opts->record_origin) {
+
+			/*
+			 * If this the message is a one-liner, append a
+			 * newline, so the second line will be empty, as
+			 * recommended.
+			 */
+			p = strstr(msgbuf.buf, "\n\n");
+			if (!p)
+				strbuf_addch(&msgbuf, '\n');
+
 			strbuf_addstr(&msgbuf, "(cherry picked from commit ");
 			strbuf_addstr(&msgbuf, sha1_to_hex(commit->object.sha1));
 			strbuf_addstr(&msgbuf, ")\n");
diff --git a/t/t3501-revert-cherry-pick.sh b/t/t3501-revert-cherry-pick.sh
index 6f489e2..858c744 100755
--- a/t/t3501-revert-cherry-pick.sh
+++ b/t/t3501-revert-cherry-pick.sh
@@ -70,6 +70,14 @@ test_expect_success 'cherry-pick after renaming branch' '
 
 '
 
+test_expect_success 'cherry-pick -x of one-liner commit message' '
+
+	git checkout rename2 &&
+	git cherry-pick -x added &&
+	git show -s --pretty=format:%s | test_must_fail grep "cherry picked"
+
+'
+
 test_expect_success 'revert after renaming branch' '
 
 	git checkout rename1 &&
-- 
1.8.1.4

Re: [PATCH] cherry-pick -x: improve handling of one-liner commit messages

[Junio C Hamano]

Miklos Vajna <vmiklos@suse.cz> writes:

> git cherry-pick -x normally just appends the "cherry picked from commit"
> line at the end of the message, which is fine. However, in case the
> original commit message had only one line, first append a newline,
> otherwise the second line won't be empty, which is against
> recommendations.
> ---

Sign-off?

I think this is part of the bc/append-signed-off-by topic that is
about to graduate to 'master'; more specifically, b971e04f54e7
(sequencer.c: always separate "(cherry picked from" from commit
body, 2013-02-12) does the equivalent, no?

>  sequencer.c                   | 10 ++++++++++
>  t/t3501-revert-cherry-pick.sh |  8 ++++++++
>  2 files changed, 18 insertions(+)
>
> diff --git a/sequencer.c b/sequencer.c
> index aef5e8a..1ae0e43 100644
> --- a/sequencer.c
> +++ b/sequencer.c
> @@ -496,6 +496,16 @@ static int do_pick_commit(struct commit *commit, struct replay_opts *opts)
>  		}
>  
>  		if (opts->record_origin) {
> +
> +			/*
> +			 * If this the message is a one-liner, append a
> +			 * newline, so the second line will be empty, as
> +			 * recommended.
> +			 */
> +			p = strstr(msgbuf.buf, "\n\n");
> +			if (!p)
> +				strbuf_addch(&msgbuf, '\n');
> +
>  			strbuf_addstr(&msgbuf, "(cherry picked from commit ");
>  			strbuf_addstr(&msgbuf, sha1_to_hex(commit->object.sha1));
>  			strbuf_addstr(&msgbuf, ")\n");
> diff --git a/t/t3501-revert-cherry-pick.sh b/t/t3501-revert-cherry-pick.sh
> index 6f489e2..858c744 100755
> --- a/t/t3501-revert-cherry-pick.sh
> +++ b/t/t3501-revert-cherry-pick.sh
> @@ -70,6 +70,14 @@ test_expect_success 'cherry-pick after renaming branch' '
>  
>  '
>  
> +test_expect_success 'cherry-pick -x of one-liner commit message' '
> +
> +	git checkout rename2 &&
> +	git cherry-pick -x added &&
> +	git show -s --pretty=format:%s | test_must_fail grep "cherry picked"
> +
> +'
> +
>  test_expect_success 'revert after renaming branch' '
>  
>  	git checkout rename1 &&

Re: [PATCH] cherry-pick -x: improve handling of one-liner commit messages

[Brandon Casey]

On Fri, Mar 29, 2013 at 10:23 AM, Junio C Hamano <gitster@pobox.com> wrote:
> Miklos Vajna <vmiklos@suse.cz> writes:
>
>> git cherry-pick -x normally just appends the "cherry picked from commit"
>> line at the end of the message, which is fine. However, in case the
>> original commit message had only one line, first append a newline,
>> otherwise the second line won't be empty, which is against
>> recommendations.
>> ---
>
> Sign-off?
>
> I think this is part of the bc/append-signed-off-by topic that is
> about to graduate to 'master'; more specifically, b971e04f54e7
> (sequencer.c: always separate "(cherry picked from" from commit
> body, 2013-02-12) does the equivalent, no?

Yeah, I think this case is already handled.

Miklos, can you check out next and see if your problem case is handled?

-Brandon

Re: [PATCH] cherry-pick -x: improve handling of one-liner commit messages

[Miklos Vajna]

[-- Attachment #1: Type: text/plain, Size: 648 bytes --]

Hi,

On Fri, Mar 29, 2013 at 10:41:17AM -0700, Brandon Casey <drafnel@gmail.com> wrote:
> > Sign-off?

Indeed, I forgot about it, my bad.

> > I think this is part of the bc/append-signed-off-by topic that is
> > about to graduate to 'master'; more specifically, b971e04f54e7
> > (sequencer.c: always separate "(cherry picked from" from commit
> > body, 2013-02-12) does the equivalent, no?
> 
> Yeah, I think this case is already handled.
> 
> Miklos, can you check out next and see if your problem case is handled?

I just checked next and right, that solves the problem I was fixing.

So -- sorry for the noise. :-)

Miklos

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [PATCH] cherry-pick -x: improve handling of one-liner commit messages

[Junio C Hamano]

Miklos Vajna <vmiklos@suse.cz> writes:

> On Fri, Mar 29, 2013 at 10:41:17AM -0700, Brandon Casey <drafnel@gmail.com> wrote:
>
>> > I think this is part of the bc/append-signed-off-by topic that is
>> > about to graduate to 'master'; more specifically, b971e04f54e7
>> > (sequencer.c: always separate "(cherry picked from" from commit
>> > body, 2013-02-12) does the equivalent, no?
>> 
>> Yeah, I think this case is already handled.
>> 
>> Miklos, can you check out next and see if your problem case is handled?
>
> I just checked next and right, that solves the problem I was fixing.
>
> So -- sorry for the noise. :-)

Don't be sorry.

People noticing an issue, trying 'master' and 'next' to see that it
has already been resolved, is the only way for us to know we are
helping people other than those who had the original itch.

The ideal would be for more people to run 'next' and report both
problems and successes ;-)