Re: [PATCH v2 00/12] Pulling signed/annotated tags
- From
Junio C Hamano <gitster@pobox.com>
- Date
- Nov 8, 2011, 05:37 UTC
- Message-ID
- <7vobwnyy2m.fsf@alter.siamese.dyndns.org>
- In-Reply-To
- <CA+55aFyEuuT25m00uakL66YKSpT-zjoiBreymFSbuHmtARq6yw@mail.gmail.com>
Linus Torvalds <torvalds@linux-foundation.org> 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: