On Thu, May 14, 2009 at 11:37:37AM +0200, Matthias Andree wrote:
> HOWEVER, I see two problems here (yes, they are corner cases):
>
> #1: git tag -f ("replace tag") fails to "replace" a heaviweight tag if I
> try to replace a tag by itself (or create a cycle by some other means).
>
> The new "foo" is unique in refs (OK), but it's *not unique* in objects
> (FAIL), as the old "foo" is referenced by the new "foo" and bears the same
> tag name.
>
> It screws the repo, breaking the uniqueness of tags. Basically, git tag -f
> is implementing a half-baked, non-working "rebase tag objects"
> functionality.
Can you explain how this "screws the repo"? The refs are unique, and in
your examples, a tag object replaced by "git tag -f" no longer has a ref
pointing to it (but in your example of making a tag of a tag, then of
course the original is still reachable indirectly). The "unique in
objects" you refer to is that the tag itself says "here is the name
under which I was tagged". That name is purely informative and has
nothing to do with ref lookup or reachability.
In your examples, I don't see any behavior that is causing actual
problems.
> #2: related: git tag -d cannot reliably delete tag objects
>
> Same here: if another tag object references the tag object I'm deleting,
> we only delete the ref, but not the tag object. It doesn't (cannot) become
> dangling.
Deleting the ref makes it dangling, unless something else is referencing
it. In your examples, since you tag the tag, the original tag is still
referenced.
> $ git rev-list --objects --all
> 4481a15d999b1b13066fe932e35ea05b8b1027a6
> 72f3463f5a8089ac91001d458ceffb6d4e1056ee foo
> 2e326d8a210536b7cd1f2bc77e3e29d7231f9ec4 foo
> 995773fc9b649922936e110207e6abb904cc18e8
> 15a9779d8f787428e57830410c7842e5449dfd33 a
The right-hand side of this output is a purely informative "here is a
name that may be useful for packing heuristics". It has nothing to do
with the refs (for blobs, the pathname through which we reached the blob
will be printed -- obviously this is not going to be unique, as you will
have many versions of each file).
> So what we get is (root/parents first, then children):
>
> objects: 4481a1 (commit) <- 2e326d (tag "foo") <- 72f346 (tag "foo")
> refs: heads/master tags/foo
>
> Whoops. "foo" is there twice, and it's referenced from a current ref.
> We have *not* *replaced* it. *If* we did, we should have got:
>
> objects: 4481a1 (commit) <- 72f346 (tag "foo")
> refs: heads/master tags/foo
> with a dangling tag 2e326d
Right. Because you didn't ask to replace it. You asked to tag the tag.
> Hu, there's a nice cycle:
>
> 69bf (commit) <- 9756 ('old' tag1) <- 38ae (tag2) <- 8e7a (tag1)
You keep calling these cycles, but they're not (at least in terms of the
git graph). The fact that two distinct objects both contain the string
"tag tag1" is not any more a cycle than two commit objects with the same
commit message. They are both distinct objects with distinct hashes, and
the hashes are how the git graph is built.
> Now, more fun - watch the inconsistency:
>
> $ git tag -d tag1
> Deleted tag 'tag1'
> $ git tag -d tag1
> error: tag 'tag1' not found.
OK, so you deleted the ref tag1.
> Ha! As if... now watch this:
> $ git rev-list --objects --all | while read a b ; do echo "$a $(git
> cat-file -t $a) $b" ; done
> 69bf327c5d172fc8e4f63acf4d2e01c474824ce4 commit
> 38aea56fec319d8c259a80157dde2432d2d09b2b tag tag2
> 9756f6fa98a5cce2aab1f6a6e7dd4de515626e19 tag tag1
> d758baa57a7ef20d44df0535bef1a91bb3dc4f62 tree
> d3d8863b140f43f7c07050b9f2e210d41e73edb1 blob otherfile
>
> The tag object "tag1" is still there. WHOOPS!!!
Of course the _old_ tag1 is still there. It is referenced by tag2, which
still has a ref. Again you are confusing the right-hand side of "git
rev-list --objects" with actual ref names.
> I appreciate that this isn't trivial to solve, but I presume anything that
> walks the object database and uses tags can fail - including, but not
> limited to, git fast-export.
I am not ruling out the possibility that there is some piece of code
that will be confused by the situation you have created, but it has
nothing to do with graph walking. It would have to be a piece of code
which cares about the uniqueness of informative names inside tag
objects.
-Peff
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html