Re: [PATCH 6/8] cogito: Don't ever assume object type in cg-object-id

[Pavel Roskin <proski@gnu.org>]

On Thu, 2005-09-22 at 17:50 +0200, Petr Baudis wrote:
> Dear diary, on Thu, Sep 22, 2005 at 05:37:59PM CEST, I got a letter
> where Pavel Roskin <proski@gnu.org> told me that...
> > [proski@dv cogito]$ for i in .git/refs/tags/*; do git-tar-tree `cat $i` >/dev/null || echo $i; done
> > fatal: not a reference to a tag, commit or tree object: 463d05c7c4fe7f24da29749f4c7f25893fc20b8c
> > .git/refs/tags/git-pasky-0.1
> > fatal: not a reference to a tag, commit or tree object: 2c70421be7d88fbee49986d7a5584d1f010a25de
> > .git/refs/tags/git-pasky-0.2
> > fatal: not a reference to a tag, commit or tree object: d14925c87cdb6ca6345bcb3c8e34a2d659c79451
> > .git/refs/tags/git-pasky-0.3
> 
> Huh. Huh?
> 
> xpasky@machine[1:0]~/git-devel$ git-cat-file -t $(cg-object-id git-pasky-0.1)
> commit

The error message is misleading.  In fact, it's the tree referred to by
the commit that was missing.  Anyway, that object exists on the server,
so it was my local problem.

It would be nice to have a script fetch an object by SHA1, possibly with
the dependencies.  git-fetch doesn't do it yet.

I copied the whole objects tree for cogito using rsync, and I see lots
or error messages from git-fsck-objects.  I'll wait for your changes to
propagate.  As it stands now, b3e9704ecdf48869f635f0aa99ddfb513f885aff
(a file you said you have removed) and
11ed64c1b141c9ba397a1ca76aef2cd250976007 are still present and empty.

Are you sure rsync that copies to kernel.org uses the "delete" option?
If not, we should treat kernel.org as "dumb transport" where directory
listings should never be used.

> > How come that cogito-0.12 - cogito-0.15 are not on the origin tree, but
> > older cogito tags are?
> 
> That's because the older tags tag commits directly, not tag objects.
> git-prune removed the tag objects because they were unreferenced by its
> perspective. Anyway, git-prune without any arguments should get it
> right.

Thanks for the explanation.  I'll be more careful with git-prune.

-- 
Regards,
Pavel Roskin