Local clone/fetch with cogito is glacial

> It appears that doing a *local* -- meaning using a file path or file URL 
> -- clone or fetch with cogito is just glacial when the repository has an 
> even moderate number of tags (and it's fetching the tags that takes all 
> the time.)  That's a really serious problem for me.
> 

> On Sun, 21 May 2006 16:47:45 -0700
> "H. Peter Anvin" <hpa@zytor.com> wrote:
> 
>> It appears that doing a *local* -- meaning using a file path or file URL 
>> -- clone or fetch with cogito is just glacial when the repository has an 
>> even moderate number of tags (and it's fetching the tags that takes all 
>> the time.)  That's a really serious problem for me.
>>
> 
> Peter, does git clone work acceptably for you?
> 

> Sean wrote:
> >On Sun, 21 May 2006 16:47:45 -0700
> >"H. Peter Anvin" <hpa@zytor.com> wrote:
> >
> >>It appears that doing a *local* -- meaning using a file path or file URL 
> >>-- clone or fetch with cogito is just glacial when the repository has an 
> >>even moderate number of tags (and it's fetching the tags that takes all 
> >>the time.)  That's a really serious problem for me.
> >>
> >
> >Peter, does git clone work acceptably for you?
> >
> 
> Well, it does, except it doesn't set up the cogito branches (which one can 
> of course copy manually.)

> 
> What about incremental fetches using git-fetch? From a quick scan of the
> git-fetch automagic tags following code, it seems to be even
> significantly more expensive than Cogito's (in terms of number of
> forks).
> 

> git-clone has an advantage here since it clones _everything_ while
> Cogito fetches only stuff related to the branch you are cloning, and
> verifying if what it fetches is sensible for you unfortunately takes a
> lot of time. :/ I guess there is no way to verify presence of multiple
> objects at once and there is also no way to order local fetch of
> multiple objects at once.

> Petr Baudis wrote:
> >git-clone has an advantage here since it clones _everything_ while
> >Cogito fetches only stuff related to the branch you are cloning, and
> >verifying if what it fetches is sensible for you unfortunately takes a
> >lot of time. :/ I guess there is no way to verify presence of multiple
> >objects at once and there is also no way to order local fetch of
> >multiple objects at once.
> 
> Note that non-local cg-clones are at least an order of magnitude faster, 
> even when the nonlocal is just git+ssh:.  One could presumably do the same 
> thing over a pipe.

> 
> Even rsync and HTTP cg-clones? git:// and git+ssh:// fetching follows an
> almost entirely different code patch and it's much more efficient since
> I just accumulate the tag object ids I want to check and then pour them
> to git-fetch-pack - I cannot do that with git-(local|http)-fetch. :-(
> 

> Petr Baudis wrote:
> >
> >Even rsync and HTTP cg-clones? git:// and git+ssh:// fetching follows an
> >almost entirely different code patch and it's much more efficient since
> >I just accumulate the tag object ids I want to check and then pour them
> >to git-fetch-pack - I cannot do that with git-(local|http)-fetch. :-(
> >
> 
> No, but git-fetch-pack could operate over a local pipe just fine (after 
> all, all it does is ssh an "git-send-pack" command to the other side.)

> 
> Even rsync and HTTP cg-clones? git:// and git+ssh:// fetching follows an
> almost entirely different code patch and it's much more efficient since
> I just accumulate the tag object ids I want to check and then pour them
> to git-fetch-pack - I cannot do that with git-(local|http)-fetch. :-(

>
> It appears that doing a *local* -- meaning using a file path or file URL -- 
> clone or fetch with cogito is just glacial when the repository has an even
> moderate number of tags (and it's fetching the tags that takes all the time.)
> That's a really serious problem for me.