Re: git-pull and tag objects

Linus Torvalds [off-list ref] writes:

But if you have pushed things out (or others could just read your 
repository directly), then others will have already seen the old tag. In 
that case you can do one of two things:
...
 - The insane thing.

   You really want to call the new version "X" too, _even_though_ others 
   have already seen the old one. So just use "git tag -f" again, as if 
   you hadn't already published the old one.

   HOWEVER!

   Git does *not* (and in my very very strong opinion, MUST NOT!) change 
   tags behind users back. So if somebody already got the old tag, doing a 
   "git pull" on your tree shouldn't just make them overwrite the old one. 

And I really think that git does the right thing. If somebody got a 
release tag from you, you cannot just change the tag for them by updating 
your own one. I think this is a BIG security issue, in that people MUST be 
able to trust their tag-names. If I got a particular tag, NO WAY IN HELL 
must git just replace it for me because you happened to have a newer one!

So if you really want to do the insane thing, you need to just fess up to 
it, and tell people that you messed up.

Confession time.

Although it is correct that the people who already saw the
original tag would not lose the tag object from their repository
when you publish a replacement tag, we have _always_ overwritten
the refs/tags/$tag to point at the new one, effectively losing
the original.

* 0a623e7c (Jul 5, 2005)
In this version "git fetch $repo tag v2.6.13" would have done just

	echo "$head" >"$GIT_DIR/$destination"

without checking if it already existed.

* ae2da406 (Aug 22, 2005)

We started checking if the fetched/followed tag already existed
with this version.  However, the result of the check was only
used to say "$tagname: updating with $new_sha1 from $old_sha1"
in the status message.

And after numerous code reorganizations of git-fetch throughout
its life, this logic has never been touched.  This comment
around ll. 170 we currently have:

    case "$1" in
    refs/tags/*)
	# Tags need not be pointing at commits so there
	# is no way to guarantee "fast-forward" anyway.

was introduced with 853a3697 (Aug 20, 2005) and stayed there
ever since.

I think it is worth fixing this by tightening the rule as you
described, even with this late in the game for 1.5.0.  The user
either needs to force it, or remove it beforehand.

diff --git a/git-fetch.sh b/git-fetch.sh
index 357cac2..1078016 100755
--- a/git-fetch.sh
+++ b/git-fetch.sh

@@ -169,14 +169,18 @@ update_local_ref () {
 
     case "$1" in
     refs/tags/*)
-	# Tags need not be pointing at commits so there
-	# is no way to guarantee "fast-forward" anyway.
+	# Tags should never be blindly overwritten without user's
+	# consent.
 	if test -n "$oldshort_"
 	then
 		if now_=$(git show-ref --hash "$1") && test "$now_" = "$2"
 		then
 			[ "$verbose" ] && echo >&2 "* $1: same as $3"
 			[ "$verbose" ] && echo >&2 "  $label_: $newshort_" ||:
+		elif test -z "$force$single_force"
+		then
+			echo >&2 "* $1: refusing to update with $3"
+			false
 		else
 			echo >&2 "* $1: updating with $3"
 			echo >&2 "  $label_: $newshort_"

On Sat, 10 Feb 2007, Junio C Hamano wrote:

Although it is correct that the people who already saw the
original tag would not lose the tag object from their repository
when you publish a replacement tag, we have _always_ overwritten
the refs/tags/$tag to point at the new one, effectively losing
the original.

* 0a623e7c (Jul 5, 2005)
In this version "git fetch $repo tag v2.6.13" would have done just

	echo "$head" >"$GIT_DIR/$destination"

without checking if it already existed.

Yes, but only if you actually explicitly asked for it, methinks.

If you just do a "git pull", it won't do it.

So I think it's ok. 

		Linus

On Sat, Feb 10, 2007 at 09:52:29PM -0800, Junio C Hamano wrote:

Although it is correct that the people who already saw the
original tag would not lose the tag object from their repository
when you publish a replacement tag, we have _always_ overwritten
the refs/tags/$tag to point at the new one, effectively losing
the original.

So I have a suspicion that I have multiple tag objects with the same
tag name (E2FSPROGS-1_26), from doing an hg conversion.  Is there an
easy way to search all of the tag objects in my git repository to see
if this is the case, so I can delete them lest they cause any
confusion/problems?

						- Ted

Theodore Tso [off-list ref] writes:

On Sat, Feb 10, 2007 at 09:52:29PM -0800, Junio C Hamano wrote:

quoted

Although it is correct that the people who already saw the
original tag would not lose the tag object from their repository
when you publish a replacement tag, we have _always_ overwritten
the refs/tags/$tag to point at the new one, effectively losing
the original.

So I have a suspicion that I have multiple tag objects with the same
tag name (E2FSPROGS-1_26), from doing an hg conversion.  Is there an
easy way to search all of the tag objects in my git repository to see
if this is the case, so I can delete them lest they cause any
confusion/problems?

"fsck --full" should report "dangling tag".

On Mon, 12 Feb 2007, Junio C Hamano wrote:

"fsck --full" should report "dangling tag".

Well, except if
 - you've pruned
 - the importer never imported anything but the most recent one.

One thing that _might_ be a good idea for tags (if people _really_ want to 
actually update tags under the same name) is to have a "parent" pointer 
for tag objects, the same way we have for commits. That way you could - if 
you really wanted to - create a chain of tags, and show the history of 
them.

Now, I personally think you'd be better off just having separate names, 
but for something like a "passed testing" tag, it might be valid to (a) 
have the last one and (b) have a history chain. And it's not like it would 
be technically "hard" to do.

I dunno. Personally I'd rather try to just tell people to not re-use 
tag-names, because it kind of destroys the whole point of a tag ("I 
checked out tag X!" just leadsto "_Which_ X?").

And you could certainly do the "passed testing" thing with commits in a 
separate branch instead: you'd create the "testing" branch, which is 
always a set of commits that have as their primary parent the commit that 
got tested, and as the second parent the previous commit in the "testing" 
series).

So _generally_ I think we're better off keeping things the way they are, 
but on the other hand, if only to work well with idiotic systems that 
mis-use tags in ways that tags shouldn't be used, we *could* just extend 
on what tyou can do with a git tag too..

		Linus

Linus Torvalds wrote:

One thing that _might_ be a good idea for tags (if people _really_ want to 
actually update tags under the same name) is to have a "parent" pointer 
for tag objects, the same way we have for commits. That way you could - if 
you really wanted to - create a chain of tags, and show the history of 
them.

Wouldn't it be better to just use reflog for given tag? That assuming of
course that we could protect tag reflog from pruning...
-- 
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git

Hi,

[*SIGH* I am Cc'ing Linus, since you -- again -- forgot that]

On Thu, 15 Feb 2007, Jakub Narebski wrote:

Linus Torvalds wrote:

quoted

One thing that _might_ be a good idea for tags (if people _really_ 
want to actually update tags under the same name) is to have a 
"parent" pointer for tag objects, the same way we have for commits. 
That way you could - if you really wanted to - create a chain of tags, 
and show the history of them.

Wouldn't it be better to just use reflog for given tag? That assuming of 
course that we could protect tag reflog from pruning...

No. Reflogs are a local thing, tags not necessarily. And much fun 
"pushing" a reflog to another repo.

Ciao,
Dscho