diff against a tag ?

diff against a tag ?

[Dave Jones]

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

Re: diff against a tag ?

[Junio C Hamano]

>>>>> "DJ" == Dave Jones <davej@redhat.com> writes:

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

Re: diff against a tag ?

[Linus Torvalds]

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.

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

Re: diff against a tag ?

[Junio C Hamano]

>>>>> "LT" == Linus Torvalds <torvalds@osdl.org> writes:

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

Re: diff against a tag ?

[Dave Jones]

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

Re: diff against a tag ?

[Linus Torvalds]

On Thu, 28 Apr 2005, Dave Jones wrote:
>
> Groovy. Is it 'THE LAW' that the first one it reports will always be
> the most recent tag ?

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

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

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

Re: diff against a tag ?

[Dave Jones]

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

Re: diff against a tag ?

[Morten Welinder]

> Right now fsck is the only thing that reports tags that aren't referenced
> some other way. 

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

Re: diff against a tag ?

[Linus Torvalds]

On Thu, 28 Apr 2005, Morten Welinder wrote:
> 
> Which begs the question: why wasn't the type of the object made part of the
> file name?

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