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.
-hpa
Quoted 5 lines · On Sun, 21 May 2006 16:47:45 -0700 "H. Peter Anvin" <[email protected]> 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
Quoted 10 lines · Sean
Quoted 4 lines · On Sun, 21 May 2006 16:47:45 -0700 "H. Peter Anvin" <[email protected]> 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.)
cg-clone probably should be rewritten as a thin wrapper around git-clone.
-hpa
Dear diary, on Mon, May 22, 2006 at 11:18:07PM CEST, I got a letter where "H. Peter Anvin" <[email protected]> said that...
Quoted 10 lines
Quoted 9 lines · Sean
Quoted 5 lines · On Sun, 21 May 2006 16:47:45 -0700 "H. Peter Anvin" <[email protected]> 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.
Quoted 5 lines
Quoted 2 lines
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.
Signature · 4 lines
Petr "Pasky" Baudis Stuff: http://pasky.or.cz/ Right now I am having amnesia and deja-vu at the same time. I think I have forgotten this before.
Quoted 6 lines · Petr Baudis
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).
Well, I haven't used git-fetch, so I can't comment on that one.
Quoted 6 lines
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.
-hpa
Dear diary, on Tue, May 23, 2006 at 12:23:44AM CEST, I got a letter where "H. Peter Anvin" <[email protected]> said that...
Quoted 11 lines
Quoted 6 lines · Petr Baudis
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. :-(
Signature · 4 lines
Petr "Pasky" Baudis Stuff: http://pasky.or.cz/ Right now I am having amnesia and deja-vu at the same time. I think I have forgotten this before.
Quoted 6 lines · Petr Baudis
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.)
-hpa
Dear diary, on Tue, May 23, 2006 at 01:03:06AM CEST, I got a letter where "H. Peter Anvin" <[email protected]> said that...
Quoted 10 lines
Quoted 6 lines · Petr Baudis
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.)
Yes, but in that case it couldn't hardlink the objects so you would see quite a big bump in disk usage if you have many local clones of the same repo.
That said, hardlinking is probably not all that big an advantage if you repack often, repack everywhere, and in the many-repositories cases it might be more sensible to use alternates (which is what cg-clone -l should really do instead of symlinking), so it might be well worth the sacrifice.
Signature · 4 lines
Petr "Pasky" Baudis Stuff: http://pasky.or.cz/ Right now I am having amnesia and deja-vu at the same time. I think I have forgotten this before.
Quoted 5 lines · Petr Baudis
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. :-(
Sure you can. Well, not to http-fetch, but git-fetch-pack should work fine for a local repo.
The git-clone script will literally special-case rsync:// and http://.
Everything else should work fine with git-fetch-pack.
Linus
Quoted 2 lines
The git-clone script will literally special-case rsync:// and http://.
Everything else should work fine with git-fetch-pack.
Aha, I overlooked that what I described goes on in git-clone happens only with git-clone -l, otherwise it indeed seems to use git-fetch-pack. Sorry about the confusion.
Signature · 4 lines
Petr "Pasky" Baudis Stuff: http://pasky.or.cz/ Right now I am having amnesia and deja-vu at the same time. I think I have forgotten this before.
Quoted 5 lines · H. Peter Anvin
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.
I think this is purely a cogito problem.
Use "git clone" instead.
Linus