# Tags of non-commits 4 messages from 2007-08-24 to 2007-08-24. Participants: Daniel Barkalow, Junio C Hamano. Thread: https://gitlist.dev/t/9637 ## Daniel Barkalow, 2007-08-24 18:11 Subject: Tags of non-commits Message-ID: URL: https://gitlist.dev/e/Pine.LNX.4.64.0708241337560.5774%40iabervon.org ``` 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, 2007-08-24 18:49 Subject: Re: Tags of non-commits Message-ID: <7vwsvkdaz0.fsf@gitster.siamese.dyndns.org> URL: https://gitlist.dev/e/7vwsvkdaz0.fsf%40gitster.siamese.dyndns.org In-Reply-To: ``` Daniel Barkalow 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, 2007-08-24 19:13 Subject: Re: Tags of non-commits Message-ID: URL: https://gitlist.dev/e/Pine.LNX.4.64.0708241506300.5774%40iabervon.org In-Reply-To: <7vwsvkdaz0.fsf@gitster.siamese.dyndns.org> ``` On Fri, 24 Aug 2007, Junio C Hamano wrote: > Daniel Barkalow 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, 2007-08-24 20:26 Subject: Re: Tags of non-commits Message-ID: <7vsl68d6gm.fsf@gitster.siamese.dyndns.org> URL: https://gitlist.dev/e/7vsl68d6gm.fsf%40gitster.siamese.dyndns.org In-Reply-To: ``` Daniel Barkalow 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. ```