# tag format and tests 3 messages from 2011-05-30 to 2011-05-30. Participants: David Glesser, Jeff King. Thread: https://gitlist.dev/t/27502 ## David Glesser, 2011-05-30 14:12 Subject: tag format and tests Message-ID: URL: https://gitlist.dev/e/db6ec478a7cb9b963d90651f5315ffec%40ensimag.fr ``` Hello, We are currently coding a minimal git client using libgit2. We use git tests to test our git client. We have an error caused by the tag format used by libgit2. The test t1006-cat-file.sh report many errors, the first one is: not ok - 23 Size of tag is correct This error comes from libgit2 and how it writes the timestamp, see below: $ cat tag && echo object 5e1c309dae7f45e0f39b1bf3ac3cd9db12e7d689 type blob tag hellotag tagger SpongeBob 0000000000 +0000 cheeseburger $ git mktag < tag 7eade44ddd1b9ee24a44e0b2dde2561efea7f7d6 $ echo 7eade44ddd1b9ee24a44e0b2dde2561efea7f7d6 | git cat-file --batch 7eade44ddd1b9ee24a44e0b2dde2561efea7f7d6 tag 154 object 5e1c309dae7f45e0f39b1bf3ac3cd9db12e7d689 type blob tag hellotag tagger SpongeBob 0000000000 +0000 cheeseburger And now using libgit2 : $ git2 mktag < tag 49bc784cd2071c97a14841b3eab1181dd1c8fbcd $ echo 49bc784cd2071c97a14841b3eab1181dd1c8fbcd | git cat-file --batch 49bc784cd2071c97a14841b3eab1181dd1c8fbcd tag 145 object 5e1c309dae7f45e0f39b1bf3ac3cd9db12e7d689 type blob tag hellotag tagger SpongeBob 0 +0000 cheeseburger Both formats are accepted by git. It's reasonable to say that the test is wrong because it doesn't fit exactly with the format ? David G. ``` ## Jeff King, 2011-05-30 16:02 Subject: Re: tag format and tests Message-ID: <20110530160203.GB24431@sigill.intra.peff.net> URL: https://gitlist.dev/e/20110530160203.GB24431%40sigill.intra.peff.net In-Reply-To: ``` On Mon, May 30, 2011 at 04:12:30PM +0200, David Glesser wrote: > This error comes from libgit2 and how it writes the timestamp, see below: > > $ cat tag && echo > object 5e1c309dae7f45e0f39b1bf3ac3cd9db12e7d689 > type blob > tag hellotag > tagger SpongeBob 0000000000 +0000 > > cheeseburger > $ git mktag < tag > 7eade44ddd1b9ee24a44e0b2dde2561efea7f7d6 > $ echo 7eade44ddd1b9ee24a44e0b2dde2561efea7f7d6 | git cat-file --batch > 7eade44ddd1b9ee24a44e0b2dde2561efea7f7d6 tag 154 > object 5e1c309dae7f45e0f39b1bf3ac3cd9db12e7d689 > type blob > tag hellotag > tagger SpongeBob 0000000000 +0000 > > cheeseburger > > > And now using libgit2 : > > $ git2 mktag < tag > 49bc784cd2071c97a14841b3eab1181dd1c8fbcd > $ echo 49bc784cd2071c97a14841b3eab1181dd1c8fbcd | git cat-file --batch > 49bc784cd2071c97a14841b3eab1181dd1c8fbcd tag 145 > object 5e1c309dae7f45e0f39b1bf3ac3cd9db12e7d689 > type blob > tag hellotag > tagger SpongeBob 0 +0000 > > cheeseburger > > Both formats are accepted by git. Yes, both are valid timestamps. And git itself, when creating a tag via "git tag", will not write silly leading zeroes. But in this test, we are using mktag, which is creating a tag object from already-formatted input. So the question is not whether the date-formatting is a problem, but rather whether mktag should do be doing _any_ modification or canonicalization of its input at all. And I think the answer is "no", because we may be handing gpg-signed contents to mktag, and any change could invalidate that signature. So libgit2 is wrong to munge the data. I imagine your code parses the buffer into a tag object, checks that it parsed properly, then writes out that object. I think instead you need to parse the buffer into a tag object, check that it parsed, and then write the _original_ buffer into a tag object. -Peff ``` ## David Glesser, 2011-05-30 16:09 Subject: Re: tag format and tests Message-ID: URL: https://gitlist.dev/e/daee28953084189497dd2f2c8988cd03%40ensimag.fr In-Reply-To: <20110530160203.GB24431@sigill.intra.peff.net> ``` On Mon, 30 May 2011 12:02:03 -0400, Jeff King wrote: > And I think the answer is "no", because we may be handing gpg-signed > contents to mktag, and any change could invalidate that signature. So > libgit2 is wrong to munge the data. Ok, I will patch libgit2. > I imagine your code parses the buffer into a tag object, checks that it > parsed properly, then writes out that object. Exactly ! Thanks for your answer. David G. ```