Tags of non-commits

Tags of non-commits

[Daniel Barkalow]

There seems to be an inconsistency between the fetch and tag over whether 
lightweight tags of non-commits are allowed. Fetch doesn't like them, but 
tag creates them without any particular fuss. I think that fetch is right 
that, if you want to tag a blob, you should use a real tag object so that 
there's something that indicates (correctly) the type of the tagged 
object. Should git-tag perhaps automatically make a tag object if the 
tagged object isn't a commit, acting as if -a was given, except that an 
empty message is used instead of invoking an editor if -m is not given? (I 
can, of course, just use git-tag that way, but it seems generally 
unfriendly to by able to get "error:" out of a sequence of purely git 
commands, even if they're sort of odd and probably not what you really 
wanted to do.

	-Daniel
*This .sig left intentionally blank*

Re: Tags of non-commits

[Junio C Hamano]

Daniel Barkalow <barkalow@iabervon.org> writes:

> There seems to be an inconsistency between the fetch and tag over whether 
> lightweight tags of non-commits are allowed. Fetch doesn't like them, but 
> tag creates them without any particular fuss.

Is your "fetch does not like them" about the automated
following?  If you say "git fetch $remote tag $that_tag" there
shouldn't be any difference.

And the difference in the automated following behaviour is
deliberate.  Lightweight ones tend to be private "anchor point"
during development (these days we need that less often, thanks
to reflogs), and annotated ones, especially the signed kinds are
meant for public consumption.

Re: Tags of non-commits

[Daniel Barkalow]

On Fri, 24 Aug 2007, Junio C Hamano wrote:

> Daniel Barkalow <barkalow@iabervon.org> writes:
> 
> > There seems to be an inconsistency between the fetch and tag over whether 
> > lightweight tags of non-commits are allowed. Fetch doesn't like them, but 
> > tag creates them without any particular fuss.
> 
> Is your "fetch does not like them" about the automated
> following?  If you say "git fetch $remote tag $that_tag" there
> shouldn't be any difference.
> 
> And the difference in the automated following behaviour is
> deliberate.  Lightweight ones tend to be private "anchor point"
> during development (these days we need that less often, thanks
> to reflogs), and annotated ones, especially the signed kinds are
> meant for public consumption.

I get a bunch of:

error: Object 0938d5832b4e40e6f440fa5c424c77b70714fb59 is a blob, not a commit

lines. I think it's either in trying to decide whether they should be put 
in FETCH_HEAD or in trying to determine reachability through them. The 
server also seems to be unable to tell that I already have the blobs, and 
sends a pack of all of them each time I pull with tags.

	-Daniel
*This .sig left intentionally blank*

Re: Tags of non-commits

[Junio C Hamano]

Daniel Barkalow <barkalow@iabervon.org> writes:

> I get a bunch of:
>
> error: Object 0938d5832b4e40e6f440fa5c424c77b70714fb59 is a blob, not a commit
>
> lines. I think it's either in trying to decide whether they should be put 
> in FETCH_HEAD or in trying to determine reachability through them.

Ah, that should be fixable.  Never noticed it.

> ...server also seems to be unable to tell that I already have the blobs, and 
> sends a pack of all of them each time I pull with tags.

That may indeed be a limitation in native protocol.