diff against a tag ?

Maybe I missed this in the discussion on tags recently (I kinda tuned out after a while on that thread).

Is there an easy way to express 'show me the diff between HEAD and 2.6.12rc3' today ?
Looking at the commit for rc3, theres nothing obvious to me distinguishing it from any other commit other than the "Linux v2.6.12-rc3" in the description, which makes it somewhat difficult to automate.

Dave

DJ> Maybe I missed this in the discussion on tags recently DJ> (I kinda tuned out after a while on that thread).

DJ> Is there an easy way to express 'show me the diff DJ> between HEAD and 2.6.12rc3' today ?

Depends on your definition of today, but with the patch below I sent today, you can say "diff-tree -p $tag $(cat .git/HEAD)".

Subject: [PATCH] Rename and extend read_tree_with_tree_or_commit_sha1
Date: Thu, 28 Apr 2005 12:15:43 -0700
Message-ID: <[email protected]>

This patch renames read_tree_with_tree_or_commit_sha1() to read_object_with_reference() and extends it to automatically dereference not just "commit" objects but "tag" objects. With this patch, you can say e.g.:

ls-tree $tag
read-tree -m $(merge-base $tag $HEAD) $tag $HEAD diff-cache $tag
diff-tree $tag $HEAD

I think Dave was wondering how to _find_ the tag in the first place, which is a different issue.

Right now fsck is the only thing that reports tags that aren't referenced some other way. Once you know the tag, things are easy - even without Junio's patch you can just do

	object=$(cat-file tag $tag | sed 's/object //;q')

and then you can just do

	diff-tree $object $(cat .git/HEAD)

or whatever you want to do.

Dave: do a "fsck --tags" in your tree, and it will talk about the tags it finds. Then you can create files like .git/refs/tags/v2.6.12-rc2 that contain pointers to those tags..

Linus

Which begs the question: why wasn't the type of the object made part of the file name?

commit-babe1234...
tag-deadbeef5678...
tree-c0ca4321...
blob-cafe8765...

That would have simplied scripts a good deal and listing all tags would be trivial.

Morten

Because it would just have complicated the code and made it less flexible.

As it is, we can open an object by just knowing its name, and by "name" I mean the true one, the SHA1. No need for "open_blob()" or anything like that. You just do

sha1_file_name(const unsigned char *sha1)

to find out what the filesystem name of the object is, and this works for _any_ object.

And thanks to this, we can pass in a sha1 _without_ knowing whether it's a tree or a commit (or a tag) and just open in. Then, when we figure out that it was a commit rather than a tree, we look up the tree instead.

Being able to open files _without_ knowing what they are is hugely useful. The user passes you a name, and you can just do the right thing.

Besides, I _still_ don't want scripts mucking around with the objects directly. Remember? They're encrypted with my super-sekrit zlib encoder ring, just because people shouldn't be mucking around in them.

Trust me, when the object directories have a million files, you'll thank me. You do _not_ want to do a readdir and try to figure out tags that way. You want to do it the way I _force_ you to do it, ie the right way.

Linus

Indeed. Sorry if I was unclear.

Groovy. Is it 'THE LAW' that the first one it reports will always be the most recent tag ?

Hmm, in a fresh rsync from your kernel tree, I get this..
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 tag 0397236d43e48e821cce5bbe6a80a1a56bb7cc3a
dangling commit 9acf6597c533f3d5c991f730c6a1be296679018e
dangling tag 9e734775f7c22d2f89943ad6c745571f1930105f

Is that last part to be expected ?

Dave

Nope. They are reported in the order they are found, which is not meaningful at all (it depends on the directory ordering, with the highest-level bits being obviously ordered by the sha1 number thanks to the subdirectory stuff).

So you can only see the name of the tag - there's no ordering. The tag-name may of course imply an ordering in itself..

It even says so: "expect dangling commits".

The tags will always be dangling, since nothing refers to them. Once you have them listed in your tag database (ie you've created files that mention them in .git/refs/tags or something), you can tell fsck about them, and fsck won't complain.

Something like

	fsck-cache --unreachable $(cat .git/refs/*/*)

would do it (and depending on exactly how cogito ends up recording them).

Linus

heh, I was hex-blinded.

great.

Dave

LT> Right now fsck is the only thing that reports tags that aren't referenced LT> some other way. Once you know the tag, things are easy - even without LT> Junio's patch you can just do
LT> object=$(cat-file tag $tag | sed 's/object //;q')
LT> and then you can just do
LT> diff-tree $object $(cat .git/HEAD)
LT> or whatever you want to do.

Of course you are right. The patch is about skipping the first step and requiring you to know what you have is a tag not a commit.

LT> Dave: do a "fsck --tags" in your tree, and it will talk about the tags it LT> finds. Then you can create files like .git/refs/tags/v2.6.12-rc2 that LT> contain pointers to those tags..

Arrrrrrrrrgh! I just did "fsck --tags" blindly X-<. Good thing I was not root.

Of course you meant "fsck-cache --tags" ;-).