Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx> 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:
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html