git "tag" objects implemented - and a re-done commit

git "tag" objects implemented - and a re-done commit

[Linus Torvalds]

Ok, I just pushed out my "tag" object implementation, and due to some
local braindamage over here, I ended up re-doing one commit, so if you
happened to pull my 'git' tree at _just_ the right time, you will have a
commit object named 06a02346f6a2e9ff113c189629ff7148f5141bb0 in your git 
repository, which is not exactly bogus, but which I ended up undoing.

So if you've been pulling my git stuff, check your "git log" for whether
you find that commit in your stuff. If you do, I guess it doesn't much
matter (ie should all merge in cleanly), but if you want to match my tree,
you should first undo it if it's your HEAD commit (by setting your HEAD to
the _parent_ of that commit, and then running the git-prune-script thing).

Anyway, I decided that my original model for tags was the right one, with 
a trivial extension. Notably, if you want to tag a single file or a tree 
object, go wild. The tag object format is:

	object <sha1>
	type <type>
	tag <tag>
	.. free-form commentary and signature of this all ..

and the "git-mktag" program verifies that the three first lines are valid 
before it accepts it and writes it as a git object.

Right now the tags don't do anything, except fsck can verify them (not the
signature - git doesn't even specify any particular format, and you may
validly have unsigned tags in your tree), and will print out something
like

	tagged commit e83c5163316f89bfbde7d9ab23ca2e25604af290 (v2.6.12-rc2)

if you were to have such a tag-object in your object database (you don't, 
because I've not generated one, but hey..)

		Linus

Re: git "tag" objects implemented - and a re-done commit

[Andreas Gal]

Are tag objects referenced by trees (and thus limited in scope) or are 
they stand-alone entities in the repository? The latter would be bad for 
shared object storages. Also, if I delete and recreate tags, will the old 
tag remain in the tree or will the file in the object storage disapear? 
So far all objects were always persistent, which is a nice property to 
have.

Andreas

On Mon, 25 Apr 2005, Linus Torvalds wrote:

> 
> Ok, I just pushed out my "tag" object implementation, and due to some
> local braindamage over here, I ended up re-doing one commit, so if you
> happened to pull my 'git' tree at _just_ the right time, you will have a
> commit object named 06a02346f6a2e9ff113c189629ff7148f5141bb0 in your git 
> repository, which is not exactly bogus, but which I ended up undoing.
> 
> So if you've been pulling my git stuff, check your "git log" for whether
> you find that commit in your stuff. If you do, I guess it doesn't much
> matter (ie should all merge in cleanly), but if you want to match my tree,
> you should first undo it if it's your HEAD commit (by setting your HEAD to
> the _parent_ of that commit, and then running the git-prune-script thing).
> 
> Anyway, I decided that my original model for tags was the right one, with 
> a trivial extension. Notably, if you want to tag a single file or a tree 
> object, go wild. The tag object format is:
> 
> 	object <sha1>
> 	type <type>
> 	tag <tag>
> 	.. free-form commentary and signature of this all ..
> 
> and the "git-mktag" program verifies that the three first lines are valid 
> before it accepts it and writes it as a git object.
> 
> Right now the tags don't do anything, except fsck can verify them (not the
> signature - git doesn't even specify any particular format, and you may
> validly have unsigned tags in your tree), and will print out something
> like
> 
> 	tagged commit e83c5163316f89bfbde7d9ab23ca2e25604af290 (v2.6.12-rc2)
> 
> if you were to have such a tag-object in your object database (you don't, 
> because I've not generated one, but hey..)
> 
> 		Linus
> -
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 

Re: git "tag" objects implemented - and a re-done commit

[Linus Torvalds]

On Mon, 25 Apr 2005, Andreas Gal wrote:
> 
> Are tag objects referenced by trees (and thus limited in scope) or are 
> they stand-alone entities in the repository? The latter would be bad for 
> shared object storages.

They are totally stand-alone, and I don't see why that would be bad for 
shared object storage.

In fact, the whole point of them is that since they are named by the SHA1 
hash of the content, there are no shared object issues. Two different tags 
by two different developers will have different names, exactly the same 
way two different releases will have different names.

And if two different developers tag exactly the same object with exactly 
the same tag-name and exactly the same signature, then they get the same 
tag object, and that's fine. They should.

> Also, if I delete and recreate tags, will the old tag remain in the tree
> or will the file in the object storage disapear?

Tags in no way affect the entry they name. When you remove - or add - a
tag object, nothing happens to anything else.

		Linus

Re: git "tag" objects implemented - and a re-done commit

[H. Peter Anvin]

Linus Torvalds wrote:
> 
> Anyway, I decided that my original model for tags was the right one, with 
> a trivial extension. Notably, if you want to tag a single file or a tree 
> object, go wild. The tag object format is:
> 
> 	object <sha1>
> 	type <type>
> 	tag <tag>
> 	.. free-form commentary and signature of this all ..
> 
> and the "git-mktag" program verifies that the three first lines are valid 
> before it accepts it and writes it as a git object.
> 
> Right now the tags don't do anything, except fsck can verify them (not the
> signature - git doesn't even specify any particular format, and you may
> validly have unsigned tags in your tree), and will print out something
> like
> 
> 	tagged commit e83c5163316f89bfbde7d9ab23ca2e25604af290 (v2.6.12-rc2)
> 
> if you were to have such a tag-object in your object database (you don't, 
> because I've not generated one, but hey..)
> 

It would be good if the tag object could permit junk lines before the 
start of the header; in particular, the standard PGP/GPG signed message 
format looks like:

-----BEGIN PGP SIGNED MESSAGE-----

object aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
type commit
tag foo
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.6 (GNU/Linux)

iQEVAwUBQm1hyWx5eAAqlgcFAQEShgf+P/PNJu5h1uAVPp9+xSy8QtIIC/1Zpl6a
2Tp22Bw0hfXUNYoJ7O9TH35wttYbcx8ArXl6JhlMIEcV7rS48H/vmTJgtBwnhLSb
epDPbOriLbCl9E0XXPHqrlmQE07H0iZn2dmLyg2REmtdffi3hjSQIkvFSHy72kOe
Ho6H+s2hzs/u/ypkQ8Cl82Saqn/Drahj9ehdXLRQ5Nsslr71MhwRCD5M0x+0Uy0B
KPjBiyyx6g/qWzIRLZOdkdbSUdXjczlGnm2wwC6/RdBDjeagDBGafaiuNQH8W3sx
psfmqKgKZkCBFFlSvwJQAsRFgnVl2vYUAftRaxMnQlCG7COIjNAsdg==
=lsn0
-----END PGP SIGNATURE-----

As an alternative, the signature can be a separate object, since the 
object SHA-1 itself acts as a verifier of its self-content; thus, all 
that is really necessary is an authorized verifier.

	-hpa

Re: git "tag" objects implemented - and a re-done commit

[Andreas Gal]

Ok, if tags are standalone objects then I don't see how they get 
propagated. Right now all I need to do to pull a version from a remote 
repository is to get the commit object and everything it depends on. Any tags 
involved would not be pulled as there are no dependencies from the commit 
object to the tag. Thats why I was asking whether they are part of any 
tree or not.

So how do we want to do this? Maybe a file TAGS right next to HEAD that 
lists all active tags in my tree by SHA1 hash? Or maybe make tags a linked 
list, with all tags refering to some parent tag? That would give a nice 
list to walk back to find older tags (again, we use something like TAG as 
root).

Andreas

On Mon, 25 Apr 2005, Linus Torvalds wrote:

> 
> 
> On Mon, 25 Apr 2005, Andreas Gal wrote:
> > 
> > Are tag objects referenced by trees (and thus limited in scope) or are 
> > they stand-alone entities in the repository? The latter would be bad for 
> > shared object storages.
> 
> They are totally stand-alone, and I don't see why that would be bad for 
> shared object storage.
> 
> In fact, the whole point of them is that since they are named by the SHA1 
> hash of the content, there are no shared object issues. Two different tags 
> by two different developers will have different names, exactly the same 
> way two different releases will have different names.
> 
> And if two different developers tag exactly the same object with exactly 
> the same tag-name and exactly the same signature, then they get the same 
> tag object, and that's fine. They should.
> 
> > Also, if I delete and recreate tags, will the old tag remain in the tree
> > or will the file in the object storage disapear?
> 
> Tags in no way affect the entry they name. When you remove - or add - a
> tag object, nothing happens to anything else.
> 
> 		Linus
> -
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 

Re: git "tag" objects implemented - and a re-done commit

[Linus Torvalds]

On Mon, 25 Apr 2005, H. Peter Anvin wrote:
> 
> It would be good if the tag object could permit junk lines before the 
> start of the header; in particular, the standard PGP/GPG signed message 
> format looks like:

No, I've already explained why git doesn't parse arbitrary junk: I want 
git to have 100% repeatable behaviour. And that very much means that if 
git doesn't understand something, it just doesn't touch it or parse it.

Here's my trivial script to generate tags in proper format. Go wild:

	#!/bin/sh
	( echo -e "object $(cat .git/HEAD)\ntype commit\ntag $1\n"; cat ) > .tmp-tag
	rm -f .tmp-tag.asc
	gpg -bsa .tmp-tag && cat .tmp-tag.asc >> .tmp-tag
	git-mktag < .tmp-tag
	rm -f .tmp-tag*

and it creates objects like this one:


	torvalds@ppc970:~/git> cat-file tag 
	ba613c023dcd03e06158caee9c0337e6b6988854
	object ec4465adb38d21966acdc9510ff15c0fe4539468
	type commit
	tag test-release
	Testing tagging
	-----BEGIN PGP SIGNATURE-----
	Version: GnuPG v1.2.4 (GNU/Linux)
	
	iD8DBQBCbVwSF3YsRnbiHLsRAliaAKCMlb6k6VAS7hxajwUtwRdzDZn9rACffVTb
	dRdDS6n+pjSAYbA6Lp11bQU=
	=JNiv
	-----END PGP SIGNATURE-----

and then you just split it at the (last occurrence of) the 

	-----BEGIN PGP SIGNATURE-----

and you can do

	torvalds@ppc970:~/git> gpg --verify tag.asc
	gpg: Signature made Mon 25 Apr 2005 02:07:30 PM PDT using DSA key ID 76E21CBB
	gpg: Good signature from "Linus Torvalds (tag signing key) <torvalds@osdl.org>"

to verify the dang thing.

And that way git never guesses anything at all, and you can use whatever 
you want to sign the things.

		Linus

Re: git "tag" objects implemented - and a re-done commit

[Linus Torvalds]

On Mon, 25 Apr 2005, Andreas Gal wrote:
> 
> Ok, if tags are standalone objects then I don't see how they get 
> propagated.

You propagate them "by hand" (which eventually obviously means "with tools
to do so").

The thing is, you _shouldn't_ be interested in my tags unless I -tell- you 
to be interested in them. 

So I'll probably just push out my tags with my archives, and then people
can verify them if they want to.

		Linus

Re: git "tag" objects implemented - and a re-done commit

[Petr Baudis]

Dear diary, on Tue, Apr 26, 2005 at 12:05:17AM CEST, I got a letter
where Linus Torvalds <torvalds@osdl.org> told me that...
> 
> 
> On Mon, 25 Apr 2005, H. Peter Anvin wrote:
> > 
> > It would be good if the tag object could permit junk lines before the 
> > start of the header; in particular, the standard PGP/GPG signed message 
> > format looks like:
> 
> No, I've already explained why git doesn't parse arbitrary junk: I want 
> git to have 100% repeatable behaviour. And that very much means that if 
> git doesn't understand something, it just doesn't touch it or parse it.
> 
> Here's my trivial script to generate tags in proper format. Go wild:
> 
> 	#!/bin/sh
> 	( echo -e "object $(cat .git/HEAD)\ntype commit\ntag $1\n"; cat ) > .tmp-tag
> 	rm -f .tmp-tag.asc
> 	gpg -bsa .tmp-tag && cat .tmp-tag.asc >> .tmp-tag
> 	git-mktag < .tmp-tag
> 	rm -f .tmp-tag*
> 
> and it creates objects like this one:
> 
> 
> 	torvalds@ppc970:~/git> cat-file tag 
> 	ba613c023dcd03e06158caee9c0337e6b6988854
> 	object ec4465adb38d21966acdc9510ff15c0fe4539468
> 	type commit
> 	tag test-release
> 	Testing tagging
> 	-----BEGIN PGP SIGNATURE-----
> 	Version: GnuPG v1.2.4 (GNU/Linux)
> 	
> 	iD8DBQBCbVwSF3YsRnbiHLsRAliaAKCMlb6k6VAS7hxajwUtwRdzDZn9rACffVTb
> 	dRdDS6n+pjSAYbA6Lp11bQU=
> 	=JNiv
> 	-----END PGP SIGNATURE-----

Could we please at least maintain the newline between the "header" and data,
like in the commit objects?

Thanks,

-- 
				Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
C++: an octopus made by nailing extra legs onto a dog. -- Steve Taylor

Re: git "tag" objects implemented - and a re-done commit

[Linus Torvalds]

On Mon, 25 Apr 2005, Linus Torvalds wrote:
> 
> So I'll probably just push out my tags with my archives, and then people
> can verify them if they want to.

Ok, for the intrepid users, you can now test to see if you can pick them 
out. fsck should make them totally obvious, and here's my public key in 
case you also want to verify the things.

Of course, since I normally don't use pgp signing etc, it's entirely 
possible that I've done something stupid, and I'm now sending you my 
secret key and my full porn-collection.

		Linus

-----BEGIN PGP PUBLIC KEY BLOCK-----
Version: GnuPG v1.2.4 (GNU/Linux)

mQGiBEJqZ4sRBADKttqQOCAxRzz5qGmo5QnSR5GTkSlPTm4lCuaVUon0qQPNrasr
cSBAOJ1MlXjhbRPrN3pAhI+taLgrWQ231zUNHxCTmWJZV3Yzxr8xJQGlfHlVOxXB
LI42tAfCjHOF7z8pPj6AGhtE2+fzq1U3mOlA/fUG4uYDOwIoPK+qgbM6SwCgulqs
DGlQKFFtFgW8HVnDftFmyZMD+wc0E9jRa9HJ3b1U3vY1jrxpoVw5QeeIZdSRnRFy
sknOHca5mlJvTidu1cs7xCuvpufw1VIVvgf4tPwXcTDEKthYEhoty+DFOqZ9R7pg
EMhjYbq+Q8yLT3OWQtUKV4B10FRYIWidnJ8y2CjLduTmB+cyj976oxEY/llLBbQM
yuDrBADDLw/3KZL5D75icA0l/uebQ6/73j8jcRoVu0gTqAdQBYL6Zv7Y0G7xHUCo
Eqgo+p2LXAeU9IoeA5/h8SNVDw4fYoqo6VQTkr+ydegHkjwlbrhOL/gxzlY1Pde1
TBi6+QCUssk0FCPMALt7M+OgFpSKx7pP2xSsDsMvvNNAmLl0JrQ0TGludXMgVG9y
dmFsZHMgKHRhZyBzaWduaW5nIGtleSkgPHRvcnZhbGRzQG9zZGwub3JnPoheBBMR
AgAeBQJCameLAhsDBgsJCAcDAgMVAgMDFgIBAh4BAheAAAoJEBd2LEZ24hy7I84A
nROHRYes4RU8btdleR0TgwJG7jMvAKCF2CingjxaC4sTL7BkFfNacTkBYLkBDQRC
ameMEAQAlJiw0IBltu5ihEXE4mFYiWHuVAoeufVJ9fONv67y6fu3efJ10PJ7AQdG
Ufez+8yxkrahyIVC77NuQLDrRfvgmrJ8sbP8xb6QEbY1bnwLeuciTolGjL+kYi17
J74iG2cQDyimnLWJm5lNqeUOz3nTW429SyLCRhXpR1lUjijiVi8AAwcD/1f4VEql
u9HHTA4S+1aoOQV5guZCr6JbYdWkAZeeFRpFSXfCae6uO8DhpD7o/8kiK3O8qP1O
yjQF0bG26iLCm8MdJCO0WQ2xsVlwrrvnNPpgRgbirOgoxHM4ESq/YV+MqXo41Hm0
ilHRM7OIbmm7uvFSlUJmUasuJRsrhibilbvNiEkEGBECAAkFAkJqZ4wCGwwACgkQ
F3YsRnbiHLsolQCfRVImDkgijhPGmwyI7T19bWltXwsAniMi9gakkN+9DT8E5kli
e8uTEk8f
=PRrZ
-----END PGP PUBLIC KEY BLOCK-----

Re: git "tag" objects implemented - and a re-done commit

[Linus Torvalds]

On Tue, 26 Apr 2005, Petr Baudis wrote:
> 
> Could we please at least maintain the newline between the "header" and data,
> like in the commit objects?

Yes, I did that in the "git-tag-script" I actually committed, although git 
doesn't currently really care (ie fsck won't complain).

		Linus

Re: git "tag" objects implemented - and a re-done commit

[Sean]

On Mon, April 25, 2005 6:39 pm, Linus Torvalds said:
>
> Ok, for the intrepid users, you can now test to see if you can pick them
out. fsck should make them totally obvious, and here's my public key in
case you also want to verify the things.
>
> Of course, since I normally don't use pgp signing etc, it's entirely
possible that I've done something stupid, and I'm now sending you my
secret key and my full porn-collection.
>


Linus,

Looks good:

$ gpg --import torvalds.pgp
$ gpg --edit-key Linus trust
gpg --edit-key Linus trust
 1 = Don't know
 2 = I do NOT trust
 3 = I trust marginally
 4 = I trust fully
 5 = I trust ultimately
 m = back to the main menu

Your decision? 5
Do you really want to set this key to ultimate trust? y



$ fsck-cache  --tags
tagged commit a2755a80f40e5794ddc20e00f781af9d6320fafb (v2.6.12-rc3) in
0397236d43e48e821cce5bbe6a80a1a56bb7cc3a
tagged commit 1da177e4c3f41524e886b7f1b8a0c1fc7321cac2 (v2.6.12-rc2) in
9e734775f7c22d2f89943ad6c745571f1930105f
expect dangling commits - potential heads - due to lack of head
information
dangling commit b453257f057b834fdf9f4a6ad6133598b79bd982



$ chksig.sh 0397236d43e48e821cce5bbe6a80a1a56bb7cc3a
gpg: Signature made Mon Apr 25 18:27:55 2005 EDT using DSA key ID 76E21CBB
gpg: Good signature from "Linus Torvalds (tag signing key)
<torvalds@osdl.org>"



chksig.sh:

#!/bin/sh
TAG=$1
cat-file tag $TAG | sed -ne '/BEGIN PGP/,/END PGP/p' > .tmp.sig
cat-file tag $TAG | sed -e '/BEGIN PGP/,/END PGP/d' | \
        gpg --verify .tmp.sig -
rm -f .tmp.sig



Sean

Re: git "tag" objects implemented - and a re-done commit

[Ryan Anderson]

On Mon, 2005-04-25 at 15:39 -0700, Linus Torvalds wrote:
> 
> On Mon, 25 Apr 2005, Linus Torvalds wrote:
> > 
> > So I'll probably just push out my tags with my archives, and then people
> > can verify them if they want to.
> 
> Ok, for the intrepid users, you can now test to see if you can pick them 
> out. fsck should make them totally obvious, and here's my public key in 
> case you also want to verify the things.
> 
> Of course, since I normally don't use pgp signing etc, it's entirely 
> possible that I've done something stupid, and I'm now sending you my 
> secret key and my full porn-collection.

(Un?)fortunately, you appear to have done it correctly.

Now, you just need to get a few people that know for certain it's really
your key to sign it and upload the signatures to the key server, and it
would be golden.

-- 
Ryan Anderson <ryan@michonline.com>

Re: git "tag" objects implemented - and a re-done commit

[Matthias Urlichs]

Hi, Linus Torvalds wrote:

> And if two different developers tag exactly the same object with exactly 
> the same tag-name and exactly the same signature, then they get the same 
> tag object, and that's fine. They should.

... except that they can't. I mean, the signature is done by different
people at different times, so it can't well be identical.

-- 
Matthias Urlichs

Re: git "tag" objects implemented - and a re-done commit

[Linus Torvalds]

On Wed, 27 Apr 2005, Matthias Urlichs wrote:
>
> Hi, Linus Torvalds wrote:
> 
> > And if two different developers tag exactly the same object with exactly 
> > the same tag-name and exactly the same signature, then they get the same 
> > tag object, and that's fine. They should.
> 
> ... except that they can't. I mean, the signature is done by different
> people at different times, so it can't well be identical.

You'd quite possibly use some shared secret key for some work. For 
example, say you're a company, and any "release person" can sign the 
work..

Also, since you can tag things without signing anything at all, it's even 
more trivial to get the same tag that way.

Signing tags really makes sense when you want somebody _else_ to trust it. 
But unsigned tags are perfectly practical from a _private_ perspective: 
let's say that you just want to remember certain events but you don't need 
to tell anybody else about them - what you'd do is to just create your own 
local tag, and there's no real reason to sign it, since you'll never tell 
anybody else about it anyway.

(One such thing could be to create a tag every time you compile and
install a new kernel: your "tag" is just a way to remember what your
installed kernel was built against, and is meaningless to anybody else.  
In fact, you might well decide to just remove such tags periodically).

		Linus