[RFC/PATCH 0/2] fix and examples for git interpret-trailers

[RFC/PATCH 0/2] fix and examples for git interpret-trailers

[Christian Couder]

As I sent version 11 of the "Add interpret-trailers builtin" only a few
days ago, I am sending now a short series on top instead of another full
version.

Christian Couder (2):
  trailer: fix to ignore any line starting with '#'
  trailer: add examples to the documentation

 Documentation/git-interpret-trailers.txt | 98 +++++++++++++++++++++++++++++++-
 t/t7513-interpret-trailers.sh            | 26 +++++++++
 trailer.c                                | 29 ++++++----
 3 files changed, 141 insertions(+), 12 deletions(-)

-- 
1.9.rc0.17.g651113e

[RFC/PATCH 1/2] trailer: fix to ignore any line starting with '#'

[Christian Couder]

It looks like the commit-msg hook is passed a commit
message that can contain lines starting with a '#'.
Those comment lines will be removed from the commit
message after the hook is run.

If we want "git interpret-trailers" to be able to
process commit messages correctly in the commit-msg
hook we need to ignore those lines.

Signed-off-by: Christian Couder <chriscool@tuxfamily.org>
---
 t/t7513-interpret-trailers.sh | 26 ++++++++++++++++++++++++++
 trailer.c                     | 29 ++++++++++++++++++-----------
 2 files changed, 44 insertions(+), 11 deletions(-)

diff --git a/t/t7513-interpret-trailers.sh b/t/t7513-interpret-trailers.sh
index 9aae721..aa63b1b 100755
--- a/t/t7513-interpret-trailers.sh
+++ b/t/t7513-interpret-trailers.sh
@@ -150,6 +150,32 @@ test_expect_success 'with 2 files arguments' '
 	test_cmp expected actual
 '
 
+test_expect_success 'with message that has comments' '
+	cat basic_message >>message_with_comments &&
+	sed -e "s/ Z\$/ /" >>message_with_comments <<-\EOF &&
+		# comment
+
+		# other comment
+		Cc: Z
+		# yet another comment
+		Reviewed-by: Johan
+		Reviewed-by: Z
+		# last comment
+
+	EOF
+	cat basic_patch >>message_with_comments &&
+	cat basic_message >expected &&
+	cat >>expected <<-\EOF &&
+		# comment
+
+		Cc: Peff
+		Reviewed-by: Johan
+	EOF
+	cat basic_patch >>expected &&
+	git interpret-trailers --trim-empty --trailer "Cc: Peff" message_with_comments >actual &&
+	test_cmp expected actual
+'
+
 test_expect_success 'with commit complex message and trailer args' '
 	cat complex_message_body >expected &&
 	sed -e "s/ Z\$/ /" >>expected <<-\EOF &&
diff --git a/trailer.c b/trailer.c
index 4d32b42..81b2c5c 100644
--- a/trailer.c
+++ b/trailer.c
@@ -644,10 +644,9 @@ static int find_patch_start(struct strbuf **lines, int count)
 /*
  * Return the (0 based) index of the first trailer line or count if
  * there are no trailers. Trailers are searched only in the lines from
- * index (count - 1) down to index 0. The has_blank_line parameter
- * tells if there is a blank line before the trailers.
+ * index (count - 1) down to index 0.
  */
-static int find_trailer_start(struct strbuf **lines, int count, int *has_blank_line)
+static int find_trailer_start(struct strbuf **lines, int count)
 {
 	int start, only_spaces = 1;
 
@@ -656,10 +655,11 @@ static int find_trailer_start(struct strbuf **lines, int count, int *has_blank_l
 	 * for a line with only spaces before lines with one ':'.
 	 */
 	for (start = count - 1; start >= 0; start--) {
+		if (lines[start]->buf[0] == '#')
+			continue;
 		if (contains_only_spaces(lines[start]->buf)) {
 			if (only_spaces)
 				continue;
-			*has_blank_line = 1;
 			return start + 1;
 		}
 		if (strchr(lines[start]->buf, ':')) {
@@ -667,13 +667,20 @@ static int find_trailer_start(struct strbuf **lines, int count, int *has_blank_l
 				only_spaces = 0;
 			continue;
 		}
-		*has_blank_line = start == count - 1 ?
-		  0 : contains_only_spaces(lines[start + 1]->buf);
 		return count;
 	}
 
-	*has_blank_line = only_spaces ? count > 0 : 0;
-	return only_spaces ? count : start + 1;
+	return only_spaces ? count : 0;
+}
+
+static int has_blank_line_before(struct strbuf **lines, int start)
+{
+	for (;start >= 0; start--) {
+		if (lines[start]->buf[0] == '#')
+			continue;
+		return contains_only_spaces(lines[start]->buf);
+	}
+	return 0;
 }
 
 static void print_lines(struct strbuf **lines, int start, int end)
@@ -688,19 +695,19 @@ static int process_input_file(struct strbuf **lines,
 			      struct trailer_item **in_tok_last)
 {
 	int count = 0;
-	int patch_start, trailer_start, has_blank_line, i;
+	int patch_start, trailer_start, i;
 
 	/* Get the line count */
 	while (lines[count])
 		count++;
 
 	patch_start = find_patch_start(lines, count);
-	trailer_start = find_trailer_start(lines, patch_start, &has_blank_line);
+	trailer_start = find_trailer_start(lines, patch_start);
 
 	/* Print lines before the trailers as is */
 	print_lines(lines, 0, trailer_start);
 
-	if (!has_blank_line)
+	if (!has_blank_line_before(lines, trailer_start - 1))
 		printf("\n");
 
 	/* Parse trailer lines */
-- 
1.9.rc0.17.g651113e

Re: [RFC/PATCH 1/2] trailer: fix to ignore any line starting with '#'

[Michael Haggerty]

On 04/27/2014 10:12 PM, Christian Couder wrote:
> It looks like the commit-msg hook is passed a commit
> message that can contain lines starting with a '#'.
> Those comment lines will be removed from the commit
> message after the hook is run.
> 
> If we want "git interpret-trailers" to be able to
> process commit messages correctly in the commit-msg
> hook we need to ignore those lines.

Shouldn't this take into account the config setting core.commentchar?

Michael

-- 
Michael Haggerty
mhagger@alum.mit.edu
http://softwareswirl.blogspot.com/

Re: [RFC/PATCH 1/2] trailer: fix to ignore any line starting with '#'

[Christian Couder]

On Mon, Apr 28, 2014 at 7:58 AM, Michael Haggerty <mhagger@alum.mit.edu> wrote:
> On 04/27/2014 10:12 PM, Christian Couder wrote:
>> It looks like the commit-msg hook is passed a commit
>> message that can contain lines starting with a '#'.
>> Those comment lines will be removed from the commit
>> message after the hook is run.
>>
>> If we want "git interpret-trailers" to be able to
>> process commit messages correctly in the commit-msg
>> hook we need to ignore those lines.
>
> Shouldn't this take into account the config setting core.commentchar?

Yes, I will have a look at that.

Thanks,
Christian.

[RFC/PATCH 2/2] trailer: add examples to the documentation

[Christian Couder]

Signed-off-by: Christian Couder <chriscool@tuxfamily.org>
---
 Documentation/git-interpret-trailers.txt | 98 +++++++++++++++++++++++++++++++-
 1 file changed, 97 insertions(+), 1 deletion(-)

diff --git a/Documentation/git-interpret-trailers.txt b/Documentation/git-interpret-trailers.txt
index 450ec54..42c2f71 100644
--- a/Documentation/git-interpret-trailers.txt
+++ b/Documentation/git-interpret-trailers.txt
@@ -134,9 +134,105 @@ If the command contains the `$ARG` string, this string will be
 replaced with the <value> part of an existing trailer with the same
 <token>, if any, before the command is launched.
 
+EXAMPLES
+--------
+
+* Configure a 'sign' trailer with a 'Signed-off-by: ' key, and then
+  add two of these trailers to a message:
++
+------------
+$ git config trailer.sign.key "Signed-off-by: "
+$ cat msg.txt
+subject
+
+message
+$ cat msg.txt | git interpret-trailers --trailer 'sign: Alice <alice@example.com>' --trailer 'sign: Bob <bob@example.com>'
+subject
+
+message
+
+Signed-off-by: Alice <alice@example.com>
+Signed-off-by: Bob <bob@example.com>
+------------
+
+* Extract the last commit as a patch, and add a 'Cc' and a
+  'Reviewed-by' trailer to it:
++
+------------
+$ git format-patch -1
+0001-foo.patch
+$ git interpret-trailers --trailer 'Cc: Alice <alice@example.com>' --trailer 'Reviewed-by: Bob <bob@example.com>' 0001-foo.patch >0001-bar.patch
+------------
+
+* Configure a 'sign' trailer with a command to automatically add a
+  'Signed-off-by: ' with the author information only if there is no
+  'Signed-off-by: ' already, and show how it works:
++
+------------
+$ git config trailer.sign.key "Signed-off-by: "
+$ git config trailer.sign.ifmissing add
+$ git config trailer.sign.ifexists doNothing
+$ git config trailer.sign.command 'echo "$(git config user.name) <$(git config user.email)>"'
+$ git interpret-trailers <<EOF
+> EOF
+
+Signed-off-by: Bob <bob@example.com>
+$ git interpret-trailers <<EOF
+> Signed-off-by: Alice <alice@example.com>
+> EOF
+
+Signed-off-by: Alice <alice@example.com>
+------------
+
+* Configure a 'fix' trailer with a command to show the subject of a
+  commit that is fixed, and show how it works:
++
+------------
+$ git config trailer.fix.key "Fixes #"
+$ git config trailer.fix.ifExists "overwrite"
+$ git config trailer.fix.command "git log -1 --oneline --format=\"%h (%s)\" --abbrev-commit --abbrev=14 \$ARG"
+$ git interpret-trailers <<EOF
+> subject
+> 
+> message
+> 
+> fix: HEAD~2
+> EOF
+subject
+
+message
+
+Fixes #fe3187489d69c4 (subject of fixed commit)
+------------
+
+* Configure a commit template with some trailers with empty values,
+  then configure a commit-msg hook that uses git interpret-trailers to
+  remove trailers with empty values and to add a 'git-version'
+  trailer:
++
+------------
+$ cat >commit_template.txt <<EOF
+> ***subject***
+> 
+> ***message***
+> 
+> Fixes: 
+> Cc: 
+> Reviewed-by: 
+> Signed-off-by: 
+> EOF
+$ git config commit.template commit_template.txt
+$ cat >.git/hooks/commit-msg <<EOF
+#!/bin/sh
+git interpret-trailers --trim-empty --trailer "git-version: \$(git describe)" "\$1" > "\$1.new"
+mv "\$1.new" "\$1"
+EOF
+$ chmod +x .git/hooks/commit-msg
+------------
+
 SEE ALSO
 --------
-linkgit:git-commit[1]
+linkgit:git-commit[1], linkgit:git-format-patch[1], linkgit:git-config[1]
 
 GIT
 ---
-- 
1.9.rc0.17.g651113e

Re: [RFC/PATCH 2/2] trailer: add examples to the documentation

[Junio C Hamano]

Christian Couder <chriscool@tuxfamily.org> writes:

> Signed-off-by: Christian Couder <chriscool@tuxfamily.org>
> ---
>  Documentation/git-interpret-trailers.txt | 98 +++++++++++++++++++++++++++++++-
>  1 file changed, 97 insertions(+), 1 deletion(-)

Very good to have these examples.  They seem to be clearly written.

Having said that, this part made me go "Huh" for a few reasons.

> +* Configure a 'fix' trailer with a command to show the subject of a
> +  commit that is fixed, and show how it works:
> ++
> +------------
> +$ git config trailer.fix.key "Fixes #"
> +$ git config trailer.fix.ifExists "overwrite"
> +$ git config trailer.fix.command "git log -1 --oneline --format=\"%h (%s)\" --abbrev-commit --abbrev=14 \$ARG"
> +$ git interpret-trailers <<EOF
> +> subject
> +> 
> +> message
> +> 
> +> fix: HEAD~2
> +> EOF
> +subject
> +
> +message
> +
> +Fixes #fe3187489d69c4 (subject of fixed commit)
> +------------

 - It makes it appear that we have a convention to prefix "#" when
   talking about a commit object name, but that is not what we
   recommend to do.  Do some projects refer to commit object names
   that way?

 - It has been my impression that "#123456", when people talk about
   "Fixes #123456", refers to a bug ID in some tracking system, and
   the scenario the example sets up "show the subject that is fixed"
   would not help those who want to have such a linkage between bug
   ID and fix.

I however do not think of a good mechanised way to fill in the bug
ID with script [*1*].  I suspect (but I am thinking aloud and am
open to better alternatives) it would be better to change this
example *not* to show use of trailer.*.command but have it just take
the bug ID literally to make it a demonstration that the trailer
does not have to end with "key: ".  We can of course have your
example to turn a commit object name to human readable one-liner as
a separate one to illustrate how to use trailer.*.command, but I do
not think it is a good idea to call it "Fixes", as that may invite
confusions with a bug ID people would expect to see.


[Footnote]

*1* A workable project convention may be to document an existing bug
    in a test-suite and detect a commit that fixes the bug, e.g.

    - Document an expected-to-fail bug like so:

      test_expect_failure 'bug #123456' '
	... demonstrate breakage ...
      '

      when it is noticed to keep track of it.


    - A commit that fixes the bug will have a hunk:

      -test_expect_failure 'bug #123456' '
      +test_expect_success 'bug #123456' '

      and the trailer.fix.command can examine "git show" output of
      the proposed commit to detect that hunk and extract "bug #"
      from there.

    Of course that is not _the_ single best convention, and it would
    be too big for an example in this documentation.