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

[Junio C Hamano <junkio@cox.net>]

Petr Baudis <pasky@suse.cz> writes:

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