[git-object] Encoding of an empty tag seems inconsistent with git's

[pierrechevalier83]

Duplicates

• I have searched the existing issues

Current behavior 😯

Currently, an annotated tag with an empty message gets encoded and decoded in the following format:

object 01dd4e2a978a9f5bd773dae6da7aa4a5ac1cdbbc
type commit
tag empty
tagger Sebastian Thiel <sebastian.thiel@icloud.com> 1592381636 +0800

as illustrated in the test fixture empty.txt.

Note that the tagger line ends with an end-of-line character and there is no other end-of-line character between that and the end of the file.

I noticed this by using this library to process the tags on an existing git repo, and it would fail to parse some tags. I created a minimal repro from there (see steps to reproduce).

Expected behavior 🤔

This seems inconsistent with the way git represents a tag with an empty message.

I would expect one more end-of-line in that file, like so:

object 01dd4e2a978a9f5bd773dae6da7aa4a5ac1cdbbc
type commit
tag empty
tagger Sebastian Thiel <sebastian.thiel@icloud.com> 1592381636 +0800

See the steps to reproduce to explain why I think this extra newline is needed for git compatibility. Am I missing something? Is there any way to generate a tag with an empty commit that git doesn't store with that extra newline? Please let me know if so.

Steps to reproduce 🕹

• Create a new git repo with an empty commit

mkdir test_repo
cd test_repo
git init
git commit -m "commit" --allow-empty

• Create an annotated tag with an empty message

git tag -a tag -m ""

• Check git's representation of this tag (using bat here so I can show the output in a pretty way and there is no ambiguity about the extra newline character)

git cat-file -p tag | bat

Output:

───────┬─────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────
       │ STDIN
───────┼─────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────
   1   │ object b1a2ffad8b8b88e79765a412eba97b5c8eee6217
   2   │ type commit
   3   │ tag tag
   4   │ tagger Pierre Chevalier <pierrechevalier83@gmail.com> 1668709561 +0000
   5   │
───────┴─────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────

[Byron]

Thanks a million for this wonderful description and reproduction of what ends up being just a single character: \n. An issue like this is a bit like a gift to keep and hold dear, so I though I'd value it with a live review here: https://youtu.be/86OA4MrYaL4 .

Am I missing something? Is there any way to generate a tag with an empty commit that git doesn't store with that extra newline? Please let me know if so.

The question is if it's possible to encounter empty.txt as it was before and if being able to parse it would be required, too, and I can't tell as I don't know if the initial empty.txt fixture was created like that by accident, newlines are easily mangled.
It's unquestionable though that it shouldn't fail parsing empty tags, so I consider this a bug.

Thanks again, I hope you won't find more of these bugs, but if you do I will always be happy to help with quick turnarounds for fixes.