{"thread":{"id":"9637","subject":"Tags of non-commits","startedAt":"2007-08-24T18:11:33Z","lastAt":"2007-08-24T20:26:49Z","messageCount":4,"participants":["Daniel Barkalow","Junio C Hamano"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"51456","messageId":"Pine.LNX.4.64.0708241337560.5774@iabervon.org","threadId":"9637","inReplyTo":null,"subject":"Tags of non-commits","fromName":"Daniel Barkalow","fromEmail":"barkalow@iabervon.org","sentAt":"2007-08-24T18:11:33Z","receivedAt":"2007-08-24T18:11:33Z","isPatch":false,"sender":{"key":"barkalow@iabervon.org","avatar":"https://avatars.githubusercontent.com/u/55364219?v=4"},"body":"There seems to be an inconsistency between the fetch and tag over whether \nlightweight tags of non-commits are allowed. Fetch doesn't like them, but \ntag creates them without any particular fuss. I think that fetch is right \nthat, if you want to tag a blob, you should use a real tag object so that \nthere's something that indicates (correctly) the type of the tagged \nobject. Should git-tag perhaps automatically make a tag object if the \ntagged object isn't a commit, acting as if -a was given, except that an \nempty message is used instead of invoking an editor if -m is not given? (I \ncan, of course, just use git-tag that way, but it seems generally \nunfriendly to by able to get \"error:\" out of a sequence of purely git \ncommands, even if they're sort of odd and probably not what you really \nwanted to do.\n\n\t-Daniel\n*This .sig left intentionally blank*\n"},{"id":"51461","messageId":"7vwsvkdaz0.fsf@gitster.siamese.dyndns.org","threadId":"9637","inReplyTo":"Pine.LNX.4.64.0708241337560.5774@iabervon.org","subject":"Re: Tags of non-commits","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2007-08-24T18:49:23Z","receivedAt":"2007-08-24T18:49:23Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Daniel Barkalow <barkalow@iabervon.org> writes:\n\n> There seems to be an inconsistency between the fetch and tag over whether \n> lightweight tags of non-commits are allowed. Fetch doesn't like them, but \n> tag creates them without any particular fuss.\n\nIs your \"fetch does not like them\" about the automated\nfollowing?  If you say \"git fetch $remote tag $that_tag\" there\nshouldn't be any difference.\n\nAnd the difference in the automated following behaviour is\ndeliberate.  Lightweight ones tend to be private \"anchor point\"\nduring development (these days we need that less often, thanks\nto reflogs), and annotated ones, especially the signed kinds are\nmeant for public consumption.\n"},{"id":"51464","messageId":"Pine.LNX.4.64.0708241506300.5774@iabervon.org","threadId":"9637","inReplyTo":"7vwsvkdaz0.fsf@gitster.siamese.dyndns.org","subject":"Re: Tags of non-commits","fromName":"Daniel Barkalow","fromEmail":"barkalow@iabervon.org","sentAt":"2007-08-24T19:13:16Z","receivedAt":"2007-08-24T19:13:16Z","isPatch":false,"sender":{"key":"barkalow@iabervon.org","avatar":"https://avatars.githubusercontent.com/u/55364219?v=4"},"body":"On Fri, 24 Aug 2007, Junio C Hamano wrote:\n\n> Daniel Barkalow <barkalow@iabervon.org> writes:\n> \n> > There seems to be an inconsistency between the fetch and tag over whether \n> > lightweight tags of non-commits are allowed. Fetch doesn't like them, but \n> > tag creates them without any particular fuss.\n> \n> Is your \"fetch does not like them\" about the automated\n> following?  If you say \"git fetch $remote tag $that_tag\" there\n> shouldn't be any difference.\n> \n> And the difference in the automated following behaviour is\n> deliberate.  Lightweight ones tend to be private \"anchor point\"\n> during development (these days we need that less often, thanks\n> to reflogs), and annotated ones, especially the signed kinds are\n> meant for public consumption.\n\nI get a bunch of:\n\nerror: Object 0938d5832b4e40e6f440fa5c424c77b70714fb59 is a blob, not a commit\n\nlines. I think it's either in trying to decide whether they should be put \nin FETCH_HEAD or in trying to determine reachability through them. The \nserver also seems to be unable to tell that I already have the blobs, and \nsends a pack of all of them each time I pull with tags.\n\n\t-Daniel\n*This .sig left intentionally blank*\n"},{"id":"51469","messageId":"7vsl68d6gm.fsf@gitster.siamese.dyndns.org","threadId":"9637","inReplyTo":"Pine.LNX.4.64.0708241506300.5774@iabervon.org","subject":"Re: Tags of non-commits","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2007-08-24T20:26:49Z","receivedAt":"2007-08-24T20:26:49Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Daniel Barkalow <barkalow@iabervon.org> writes:\n\n> I get a bunch of:\n>\n> error: Object 0938d5832b4e40e6f440fa5c424c77b70714fb59 is a blob, not a commit\n>\n> lines. I think it's either in trying to decide whether they should be put \n> in FETCH_HEAD or in trying to determine reachability through them.\n\nAh, that should be fixable.  Never noticed it.\n\n> ...server also seems to be unable to tell that I already have the blobs, and \n> sends a pack of all of them each time I pull with tags.\n\nThat may indeed be a limitation in native protocol.\n"}]}