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: <7vu0lq7lwg.fsf@assigned-by-dhcp.cox.net>

    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

On Thu, 28 Apr 2005, Junio C Hamano wrote:

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

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" ;-).

On Thu, Apr 28, 2005 at 02:01:40PM -0700, Linus Torvalds wrote:
 > 
 > 
 > On Thu, 28 Apr 2005, Junio C Hamano wrote:
 > > 
 > > Depends on your definition of today, but with the patch below I
 > > sent today, you can say "diff-tree -p $tag $(cat .git/HEAD)".
 > 
 > I think Dave was wondering how to _find_ the tag in the first place, which 
 > is a different issue.

Indeed. Sorry if I was unclear.

 > 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..

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

On Thu, 28 Apr 2005, Dave Jones wrote:

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

On Thu, Apr 28, 2005 at 03:22:21PM -0700, Linus Torvalds wrote:

 > > 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 ?
 > It even says so: "expect dangling commits".

heh, I was hex-blinded.
 
 > 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).

great.

		Dave

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

On Thu, 28 Apr 2005, Morten Welinder wrote:

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