threads / discuss / 9637

Tags of non-commits

Subject: Tags of non-commits

## tl;dr

4 messages between Aug 24, 2007 and Aug 24, 2007.

replies: 3people: 2as markdown or json

Daniel Barkalow· Aug 24, 2007, 18:11 UTC · lore

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*

Junio C Hamano· Aug 24, 2007, 18:49 UTC · re: Daniel Barkalow · lore

Re: Tags of non-commits

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.

Daniel Barkalow· Aug 24, 2007, 19:13 UTC · re: Junio C Hamano · lore

Re: Tags of non-commits

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

Show 15 quoted lines

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

Junio C Hamano· Aug 24, 2007, 20:26 UTC · re: Daniel Barkalow · lore

Re: Tags of non-commits

Daniel Barkalow <barkalow@iabervon.org> writes:

Show 6 quoted lines

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