Re: git-tag bug? confusing git fast-export with double tag objects

From: Matthias Andree <matthias.andree@gmx.de>
Date: May 14, 2009, 22:35 UTC
Message-ID: <op.utxydvnu1e62zd@merlin.emma.line.org>
In-Reply-To: <20090514182249.GA11919@sigill.intra.peff.net>

Am 14.05.2009, 20:22 Uhr, schrieb Jeff King <peff@peff.net>:

Show 27 quoted lines

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

Show 5 quoted lines

> 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