From: Linus Torvalds Date: Mon, 25 Apr 2005 19:25:15 GMT Subject: git "tag" objects implemented - and a re-done commit Message-ID: 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 type 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