From: Junio C Hamano Date: Tue, 08 Nov 2011 05:37:05 GMT Subject: Re: [PATCH v2 00/12] Pulling signed/annotated tags Message-ID: <7vobwnyy2m.fsf@alter.siamese.dyndns.org> In-Reply-To: Linus Torvalds writes: > But I don't have any really strong opinions on it. I just think it's a > good idea to make it easy to parse both mechanically and > human-visually, and "number of lines" doesn't strike me as being very > human-friendly. Here is what I had in mind. An empty line in the tag payload would become "mergetag \n" and a separate would become "mergetag\n". The consumer of "cat-file commit" would be able to tell between the two anyway and if a human _really_ cares, s/he can pipe it to "cat -e" or something. Honestly, I do not care too much about human readability of "mergetag" header. We could even store zlib-deflate-and-then-base85 the payload, which _might_ be a better solution. For one thing, it would protect us from potential NUL in the tag payload ;-). commit.c | 2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) diff --git a/commit.c b/commit.c index 7d471a3..6a5d40e 100644 --- a/commit.c +++ b/commit.c @@ -868,6 +868,8 @@ static void handle_signed_tag(struct strbuf *signed_tags, struct commit *parent) * if (verify_signed_buffer(buf, len, buf + len, size - len, &sig)) * warn("warning: signed tag unverified."); */ + if (signed_tags->len) + strbuf_addstr(signed_tags, "mergetag\n"); strbuf_add_lines(signed_tags, "mergetag ", buf, size); free_return: