Re: Cogito: cg-clone doesn't like packed tag objects

From: Junio C Hamano <junkio@cox.net>
Date: Sep 27, 2005, 04:46 UTC
Message-ID: <7vr7bb5d8w.fsf@assigned-by-dhcp.cox.net>
In-Reply-To: <20050926222944.GG26340@pasky.or.cz>

Petr Baudis <pasky@suse.cz> writes:

Show 8 quoted lines

> Yes - so you can't save the tag objects either, but then
> you'll re-slurp them again and again, which is kind of
> silly. Alternatively, you could actually make git-fsck-object
> silent about the case when an unreachable (not referenced in
> refs/) tag object references a non-existing object - perhaps
> unless --strict is passed to it. If you think the rest of my
> logic is ok, I think this change to facilitate this "tags
> caching" is not unreasonable.

Now you completely lost me. I really do not understand what you mean by tags caching and re-slurping.

If your user _is_ interested in the tag, say v0.99.7d, wouldn't it make sense to make sure that, after the user fetches the tag, the user can build v0.99.7d point release as well? What do you think the reason is when your user says he is interested in another tag, junio-gpg-pub? Wouldn't it be the most natural interpretation that he wants to get the blob the tag refers to, so that he can use it with git-verify-tag? What good does it do for the user if you get only the tag object and do not get the blob the tag refers to? Yes, he can say "git cat-file tag junio-gpg-pub", but that by itself is not that interesting if it cannot be used to validate the other tags (or itself).

If the users ask for a tag, I think it is easier for them to understand if you made sure you give them the complete set of objects that need to support that tag, at least by default. Giving the user an option to override it to make a sparse, incomplete, fsck-unclean repository is fine as a spacesaver option, but I think that should be left for "more advanced users" who understand the ramification of using the option.

I happen to publish maint branch, but I could have done without. I can make a temporary branch out of v0.99.7c tag, add fixes to extend that branch, tag the branch head as v0.99.7d, and delete the temporary branch without publishing it at all.

The tree needed to build v0.99.7d point release would be only reachable by fetching that tag (and here, "fetching the tag" really means "making sure the receiving repository has the tag object, and all the objects that are reachable from that tag object"), so "fetching only the tag object and not the object it refers to" in that case does not make much sense for the end user. Yes, he can say "git cat-file tag v0.99.7d", but that by itself is not that interesting if he cannot use it to build that release.