[PATCH 0/2] cosmetic improvements for "git show tag"

[PATCH 0/2] cosmetic improvements for "git show tag"

[Jeff King]

Right now, if you do:

  $ git tag -m 'annotated tag message' foo
  $ git show foo

you get:

    tag foo
    Tagger: Jeff King <peff@peff.net>
    Date:   Fri Jul 17 19:10:54 2009 -0400


    annotated tag message
    commit 88c17f18d7f3091508218b36a17cdf0dfd56ae65
    Author: Jeff King <peff@peff.net>
    Date:   Fri Jul 17 19:10:50 2009 -0400

        commit message

    diff ...

which is IMHO quite hard to read. These two one-liner patches improve
the output to:

    tag foo
    Tagger: Jeff King <peff@peff.net>
    Date:   Fri Jul 17 19:10:54 2009 -0400

    annotated tag message

    commit 88c17f18d7f3091508218b36a17cdf0dfd56ae65
    Author: Jeff King <peff@peff.net>
    Date:   Fri Jul 17 19:10:50 2009 -0400

        commit message

    diff ...

which I find much more readable. The changes are localized to "git
show", and since it is porcelain, I don't think there should be any
negative fallout by changing the output.

---
Jeff King (2):
  show: suppress extra newline when showing annotated tag
  show: add space between tag body and tagged object

 builtin-log.c |    3 ++-
 1 files changed, 2 insertions(+), 1 deletions(-)

[PATCH 1/2] show: suppress extra newline when showing annotated tag

[Jeff King]

When showing a tag, our header parsing finishes with the
offset pointing to the newline separating the tag header
from the tag body. This means that the printed body will
always start with a newline.

However, we also add an extra newline when printing the
tagger information. This leads to an ugly double-newline:

    $ git show v1.6.3
    tag v1.6.3
    Tagger: Junio C Hamano <gitster@pobox.com>
    Date:   Wed May 6 18:16:47 2009 -0700

    GIT 1.6.3
    -----BEGIN PGP SIGNATURE-----
    ...

This patch removes the extra newline from the end of the
tagger headers. This is a better solution than suppressing
the separator newline, because it retains the behavior for
tags which have no tagger. E.g., "git show v0.99" will
continue to look like:

      $ git show v0.99
      tag v0.99

      Test-release for wider distribution.
      ...

Signed-off-by: Jeff King <peff@peff.net>
---
I tried to consider the output for real-world cases. In theory, you
could have a corrupted tag with not only no body, but no newline
separator. Then it would display as:

  tag foo
  commit ...

with no extra newline. But since nothing should be generating such a
tag, I don't think it is a problem.

 builtin-log.c |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/builtin-log.c b/builtin-log.c
index 0c2fa0a..b05796d 100644
--- a/builtin-log.c
+++ b/builtin-log.c
@@ -257,7 +257,7 @@ static void show_tagger(char *buf, int len, struct rev_info *rev)
 	pp_user_info("Tagger", rev->commit_format, &out, buf, rev->date_mode,
 		git_log_output_encoding ?
 		git_log_output_encoding: git_commit_encoding);
-	printf("%s\n", out.buf);
+	printf("%s", out.buf);
 	strbuf_release(&out);
 }
 
-- 
1.6.4.rc1.174.g317bf.dirty

[PATCH 1/2] Re: show: suppress extra newline when showing annotated tag

[Nicolas Sebrecht]

The 17/07/09, Jeff King wrote:

> However, we also add an extra newline when printing the
> tagger information. This leads to an ugly double-newline:

I can't see the double-newline.

>     $ git show v1.6.3
>     tag v1.6.3
>     Tagger: Junio C Hamano <gitster@pobox.com>
>     Date:   Wed May 6 18:16:47 2009 -0700
> 
>     GIT 1.6.3
>     -----BEGIN PGP SIGNATURE-----
>     ...

I guess you meant:

     $ git show v1.6.3
     tag v1.6.3
     Tagger: Junio C Hamano <gitster@pobox.com>
     Date:   Wed May 6 18:16:47 2009 -0700

 
     GIT 1.6.3
     -----BEGIN PGP SIGNATURE-----
     ...

-- 
Nicolas Sebrecht

Re: [PATCH 1/2] Re: show: suppress extra newline when showing annotated tag

[Jeff King]

On Sat, Jul 18, 2009 at 05:25:27AM +0200, Nicolas Sebrecht wrote:

> I can't see the double-newline.
> [...]
> I guess you meant:
> 
>      $ git show v1.6.3
>      tag v1.6.3
>      Tagger: Junio C Hamano <gitster@pobox.com>
>      Date:   Wed May 6 18:16:47 2009 -0700
> 
>  
>      GIT 1.6.3
>      -----BEGIN PGP SIGNATURE-----
>      ...

Urgh, sorry, yes. I accidentally cut-and-pasted from the _fixed_
version. :)

-Peff

[PATCH 2/2] show: add space between tag body and tagged object

[Jeff King]

When showing an annotated tag, "git show" will always
display the pointed-to object. However, it didn't separate
the two with whitespace, making it more difficult to notice
where the new object started. For example:

  $ git tag -m 'my message' foo
  $ git show foo
  tag foo
  Tagger: Jeff King <peff@peff.net>
  Date:   Fri Jul 17 18:46:25 2009 -0400

  my message
  commit 41cabf8fed2694ba33e01d64f9094f2fc5e5805a
  Author: Jeff King <peff@peff.net>
  Date:   Thu Jul 16 17:31:34 2009 -0400
  ...

This patch adds a blank line between "my message" and
"commit 41c...", making it easier to read.

Signed-off-by: Jeff King <peff@peff.net>
---
I was tempted to add logic for "put a blank line separator between each
two items printed by git show", instead of just tags. But:

  - commits already do that (e.g., "git show HEAD HEAD^" looks fine)

  - blobs don't do it, but you probably don't want them to. I don't know
    why you would really do "git show HEAD:foo HEAD:bar", but you could,
    and I would expect it to concatenate them without extra data.

Trees don't do it, so if you "git show HEAD^{tree} HEAD^{tree}" there is
no separator. Maybe that is worth fixing separately, but I find it
unlikely for somebody to do that. Annotated tags are the much more
common case, because you always get two objects displayed.

 builtin-log.c |    1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

diff --git a/builtin-log.c b/builtin-log.c
index b05796d..d3e4d1a 100644
--- a/builtin-log.c
+++ b/builtin-log.c
@@ -342,6 +342,7 @@ int cmd_show(int argc, const char **argv, const char *prefix)
 					    sha1_to_hex(t->tagged->sha1));
 			objects[i].item = o;
 			i--;
+			putchar('\n');
 			break;
 		}
 		case OBJ_TREE:
-- 
1.6.4.rc1.174.g317bf.dirty

[PATCH 0/2] Re: cosmetic improvements for "git show tag"

[Nicolas Sebrecht]

The 17/07/09, Jeff King wrote:

>                                   These two one-liner patches improve
> the output to:
> 
>     tag foo
>     Tagger: Jeff King <peff@peff.net>
>     Date:   Fri Jul 17 19:10:54 2009 -0400
> 
>     annotated tag message
> 
>     commit 88c17f18d7f3091508218b36a17cdf0dfd56ae65
>     Author: Jeff King <peff@peff.net>
>     Date:   Fri Jul 17 19:10:50 2009 -0400
> 
>         commit message
> 
>     diff ...
> 
> which I find much more readable. 

Nice. What about adding an extra newline between tags?

  $ git tag v1.6.1 v1.6.2

	<snip>

  +  link:RelNotes-1.6.1.txt[1.6.1].
  +
   * link:v1.6.0.6/git.html[documentation for release 1.6.0.6]
   
   * release notes for
  tag v1.6.2
  Tagger: Junio C Hamano <gitster@pobox.com>
  Date:   Tue Mar 3 23:37:25 2009 -0800

  <snip>

IOW, between " * release notes for" and "tag v1.6.2" here.

-- 
Nicolas Sebrecht

Re: [PATCH 0/2] Re: cosmetic improvements for "git show tag"

[Jeff King]

On Sat, Jul 18, 2009 at 03:10:06AM +0200, Nicolas Sebrecht wrote:

> Nice. What about adding an extra newline between tags?
> 
>   $ git tag v1.6.1 v1.6.2
> 
> 	<snip>
> 
>   +  link:RelNotes-1.6.1.txt[1.6.1].
>   +
>    * link:v1.6.0.6/git.html[documentation for release 1.6.0.6]
>    
>    * release notes for
>   tag v1.6.2
>   Tagger: Junio C Hamano <gitster@pobox.com>
>   Date:   Tue Mar 3 23:37:25 2009 -0800
> 
>   <snip>
> 
> IOW, between " * release notes for" and "tag v1.6.2" here.

Hmph. I thought that should just work, because of the newline after the
commit. But it seems that you only get that if the next thing is a
commit. Hrm.. and it is even worse. The code to print that newline comes
from printing the second commit, which says "oh, we've already printed a
commit" and adds the newline.

So when you show two tags you get:

  tag foo

  message

  commit foo^{}

  message
  tag bar


  commit bar^{}

That is, the newline is actually stuck in the wrong place. So we
actually need to turn that newline off, which I'm not sure is possible.
I'll look into it more.

-Peff

Re: [PATCH 0/2] Re: cosmetic improvements for "git show tag"

[Jeff King]

On Fri, Jul 17, 2009 at 09:47:43PM -0400, Jeff King wrote:

> So when you show two tags you get:
> 
>   tag foo
> 
>   message
> 
>   commit foo^{}
> 
>   message
>   tag bar
> 
> 
>   commit bar^{}
> 
> That is, the newline is actually stuck in the wrong place. So we
> actually need to turn that newline off, which I'm not sure is possible.
> I'll look into it more.

The code calls into log_tree_commit, which uses the "shown_one" member
of rev_info to determine. So we should be able to just use that for our
tags, and everything will work fine.

I think we can replace 2/2 with the patch below, which also covers the
tree case neatly.

-- >8 --
Subject: [PATCH] show: add space between multiple items

When showing an annotated tag, "git show" will always
display the pointed-to object. However, it didn't separate
the two with whitespace, making it more difficult to notice
where the new object started. For example:

  $ git tag -m 'my message' foo
  $ git show foo
  tag foo
  Tagger: Jeff King <peff@peff.net>
  Date:   Fri Jul 17 18:46:25 2009 -0400

  my message
  commit 41cabf8fed2694ba33e01d64f9094f2fc5e5805a
  Author: Jeff King <peff@peff.net>
  Date:   Thu Jul 16 17:31:34 2009 -0400
  ...

This patch respects and sets the rev.shown_one member to
prepend a blank line before showing a second item. We use
this member of rev_info instead of a local flag, because the
log_tree_commit we call into for showing commits already
respects and sets that flag. Meaning that everything will be
spaced properly if you intermix commits and tags, like:

  $ git show v1.6.3 v1.6.2 HEAD

In that case, a single blank line will separate the first
tag, the commit it points to, the second tag, the commit
that one points to, and the final commit.

While we're at it, let's also support trees, so that even
something as crazy as

  $ git show HEAD^{tree} HEAD~1^{tree} HEAD

will also be spaced in an easy-to-read way. However, we
intentionally do _not_ insert blank lines for blobs, so
that specifying multiple blobs gives a strict concatenation.

Signed-off-by: Jeff King <peff@peff.net>
---
 builtin-log.c |    6 ++++++
 1 files changed, 6 insertions(+), 0 deletions(-)

diff --git a/builtin-log.c b/builtin-log.c
index b05796d..3035816 100644
--- a/builtin-log.c
+++ b/builtin-log.c
@@ -329,11 +329,14 @@ int cmd_show(int argc, const char **argv, const char *prefix)
 		case OBJ_TAG: {
 			struct tag *t = (struct tag *)o;
 
+			if (rev.shown_one)
+				putchar('\n');
 			printf("%stag %s%s\n",
 					diff_get_color_opt(&rev.diffopt, DIFF_COMMIT),
 					t->tag,
 					diff_get_color_opt(&rev.diffopt, DIFF_RESET));
 			ret = show_object(o->sha1, 1, &rev);
+			rev.shown_one = 1;
 			if (ret)
 				break;
 			o = parse_object(t->tagged->sha1);
@@ -345,12 +348,15 @@ int cmd_show(int argc, const char **argv, const char *prefix)
 			break;
 		}
 		case OBJ_TREE:
+			if (rev.shown_one)
+				putchar('\n');
 			printf("%stree %s%s\n\n",
 					diff_get_color_opt(&rev.diffopt, DIFF_COMMIT),
 					name,
 					diff_get_color_opt(&rev.diffopt, DIFF_RESET));
 			read_tree_recursive((struct tree *)o, "", 0, 0, NULL,
 					show_tree_object, NULL);
+			rev.shown_one = 1;
 			break;
 		case OBJ_COMMIT:
 			rev.pending.nr = rev.pending.alloc = 0;
-- 
1.6.4.rc1.177.g80fb1.dirty

Re: [PATCH 0/2] Re: cosmetic improvements for "git show tag"

[Junio C Hamano]

Jeff King <peff@peff.net> writes:

> The code calls into log_tree_commit, which uses the "shown_one" member
> of rev_info to determine. So we should be able to just use that for our
> tags, and everything will work fine.
>
> I think we can replace 2/2 with the patch below, which also covers the
> tree case neatly.

Ack.  Looks sane.

Thanks.