Is there any way to make Cogito use git-fetch-pack instead of git-ssh-fetch? git+ssh:// seems to invoke the latter.
-hpa
threads / discuss / 1928
How to make Cogito use git-fetch-pack?
Subject: How to make Cogito use git-fetch-pack?
Petr BaudisRe: How to make Cogito use git-fetch-pack?
Dear diary, on Sat, Sep 24, 2005 at 12:20:08AM CEST, I got a letter where "H. Peter Anvin" <hpa@zytor.com> told me that...
> Is there any way to make Cogito use git-fetch-pack instead of > git-ssh-fetch? git+ssh:// seems to invoke the latter.
I just added git+packed+ssh:// to be used for this purpose.
-- Petr "Pasky" Baudis Stuff: http://pasky.or.cz/ VI has two modes: the one in which it beeps and the one in which it doesn't.
Re: How to make Cogito use git-fetch-pack?
Petr Baudis wrote:
Show 8 quoted lines
> Dear diary, on Sat, Sep 24, 2005 at 12:20:08AM CEST, I got a letter > where "H. Peter Anvin" <hpa@zytor.com> told me that... > >>Is there any way to make Cogito use git-fetch-pack instead of >>git-ssh-fetch? git+ssh:// seems to invoke the latter. > > I just added git+packed+ssh:// to be used for this purpose. >
Since git tends to use "pack" (e.g. git-fetch-pack) I'd suggest use git+pack+ssh:// instead. It's shorter, too.
-hpa
Re: How to make Cogito use git-fetch-pack?
H. Peter Anvin wrote:
Show 15 quoted lines
> Petr Baudis wrote: > >> Dear diary, on Sat, Sep 24, 2005 at 12:20:08AM CEST, I got a letter >> where "H. Peter Anvin" <hpa@zytor.com> told me that... >> >>> Is there any way to make Cogito use git-fetch-pack instead of >>> git-ssh-fetch? git+ssh:// seems to invoke the latter. >> >> >> I just added git+packed+ssh:// to be used for this purpose. >> > > Since git tends to use "pack" (e.g. git-fetch-pack) I'd suggest use > git+pack+ssh:// instead. It's shorter, too. >
I thought some more about this, and realized that it really doesn't make sense for there to be another name for this. Simply put, git+ssh:// requires ssh access and git to be present on the other side, and within those parameters it should use whatever access method is most effective. Thus, having a separate URL type only makes sense if something is fundamentally and user-visibly different between the two.
-hpa
Petr BaudisRe: How to make Cogito use git-fetch-pack?
Dear diary, on Mon, Sep 26, 2005 at 08:10:33PM CEST, I got a letter where "H. Peter Anvin" <hpa@zytor.com> told me that...
Show 23 quoted lines
> H. Peter Anvin wrote: > >Petr Baudis wrote: > > > >>Dear diary, on Sat, Sep 24, 2005 at 12:20:08AM CEST, I got a letter > >>where "H. Peter Anvin" <hpa@zytor.com> told me that... > >> > >>>Is there any way to make Cogito use git-fetch-pack instead of > >>>git-ssh-fetch? git+ssh:// seems to invoke the latter. > >> > >> > >>I just added git+packed+ssh:// to be used for this purpose. > >> > > > >Since git tends to use "pack" (e.g. git-fetch-pack) I'd suggest use > >git+pack+ssh:// instead. It's shorter, too. > > > > I thought some more about this, and realized that it really doesn't make > sense for there to be another name for this. Simply put, git+ssh:// > requires ssh access and git to be present on the other side, and within > those parameters it should use whatever access method is most effective. > Thus, having a separate URL type only makes sense if something is > fundamentally and user-visibly different between the two.
Tags fetching. I agree that the difference isn't that big other than this (contrary to the other fetchers, ssh-fetch won't reproduce the pack setup; this may sound as a bad thing, but it prevents transfer of redundant data which is pretty much inevitable (or for free) for the other fetchers). And since we will probably move to the pack fetchers for tags as well, I agree that there indeed is little point in this. I will switch all the git+ssh fetching to it after I implement the new tags fetching.
By the way, how much more CPU-intensive are the pack-based methods in practice, especially on the server (packing) side? Could it be noticeable?
-- Petr "Pasky" Baudis Stuff: http://pasky.or.cz/ VI has two modes: the one in which it beeps and the one in which it doesn't.