cg-pull to pull branches, not the whole repository

cg-pull to pull branches, not the whole repository

[Pavel Roskin]

Hello!

I believe cg-pull should be changed to pull only the objects relevant to
the branch rather than the whole repository.  This could be more
expensive in terms of processor power (since the objects would be
checked for parents), but it would save the bandwidth, especially for
users tracking stable branches with little changes in presence of
heavily changed development branches in the same repository.

To keep things simple, pulling the whole repository should be removed
from cogito.  Users don't need objects that are not reachable from any
branch known to cogito.  If I'm not tracking a branch, I don't want
objects from it.  To compensate for intermittently connected users,
cg-pull could have an option to pull from all branches (or from all
branches marked for automatic pull).

Ideally, cogito should not rely on the server being able to list
directories.  This would allow support more protocols and servers, e.g.
http servers without directory listings.  Unfortunately, listings are
still needed to get refs/tags and refs/heads.  Any fix for that would
involve git core, and I don't see an elegant fix.

For git+ssh protocol, git-fetch-pack already provides a server side
solution.  Client side support would be needed for http and rsync.

I'd like to hear comments before I attempt any hacking in this
direction.

-- 
Regards,
Pavel Roskin

Re: cg-pull to pull branches, not the whole repository

[Junio C Hamano]

Pavel Roskin <proski@gnu.org> writes:

> ...  Unfortunately, listings are
> still needed to get refs/tags and refs/heads.  Any fix for that would
> involve git core, and I don't see an elegant fix.

All the necessary "core" support should already be there, except
for the client side support.  Please look at yesterday's thread
with title "dumb transports not being welcomed".

> For git+ssh protocol, git-fetch-pack already provides a server side
> solution.  Client side support would be needed for http and rsync.
>
> I'd like to hear comments before I attempt any hacking in this
> direction.

Personally I think Cogito should be able to just call git-fetch
to implement cg-pull -- I do not claim the current git-fetch has
everything needed (incapable of using objects/info/alternates is
an example), but we should be able to fix and enhance just one
program to make everybody happy, not two.

Re: cg-pull to pull branches, not the whole repository

[Petr Baudis]

Dear diary, on Wed, Sep 14, 2005 at 11:31:56PM CEST, I got a letter
where Pavel Roskin <proski@gnu.org> told me that...
> Hello!

Hello,

> I believe cg-pull should be changed to pull only the objects relevant to
> the branch rather than the whole repository.

well, that should be the case for all the methods but rsync. Actually,
it's not the case for local pulls now either, because git-local-pull
wasn't able to deal with packs, but I think that's fixed by now so I'll
reenable that.

> Ideally, cogito should not rely on the server being able to list
> directories.  This would allow support more protocols and servers, e.g.
> http servers without directory listings.  Unfortunately, listings are
> still needed to get refs/tags and refs/heads.  Any fix for that would
> involve git core, and I don't see an elegant fix.

Well, there's that update-server-info thing. It'd be nice if
git-send-pack could call that automagically or something, so it's kept
up-to-date. But I have no idea about how expensive can the command
actually be.

-- 
				Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
If you want the holes in your knowledge showing up try teaching
someone.  -- Alan Cox

Re: cg-pull to pull branches, not the whole repository

[Pavel Roskin]

On Wed, 2005-09-14 at 15:05 -0700, Junio C Hamano wrote:
> Pavel Roskin <proski@gnu.org> writes:
> 
> > ...  Unfortunately, listings are
> > still needed to get refs/tags and refs/heads.  Any fix for that would
> > involve git core, and I don't see an elegant fix.
> 
> All the necessary "core" support should already be there, except
> for the client side support.  Please look at yesterday's thread
> with title "dumb transports not being welcomed".

Great.  It looks like my concerns are fully understood and the work is
underway to address them.  Sorry for the noise.

-- 
Regards,
Pavel Roskin