Am 14.05.2009, 20:22 Uhr, schrieb Jeff King <peff@xxxxxxxx>:
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.
Hi Jeff,
so you, Alex and Brandon say git doesn't malfunction here. Hope you don't
mind my insisting, and to keep this concise, I'll send only one answer to
several posts (the whole discussion is too verbose already).
I agree that the resulting object structure is still a directed acyclic
graph, so I'll not criticize the object structure.
The semantic meaning however is missing. Let me take a different vantage
and look at the same situation, leaving the object graph aside.
This "git tag -f -s same same" operation gives me a signed nothing, and
the ref indeed no longer points to the old tag. But what's the new
signature or tag good for? I tagged & signed an object that was removed
in the process. I have a tagged and signed nothing. (Yes, there is an
underlying object, but it takes lots of fiddling with the LL tools to get
at it.)
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.
That's what I see, yes. But again, what good is the signed nothing?
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.
Indeed it's not git show-ref...
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.
That's true, and apparently git fast-export is one of those pieces of code.
Thanks
--
Matthias Andree
--
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