Subject: Re: GSoC 2009 Prospective student

From: Jakub Narebski <[email-masked]>
Date: Mon, 23 Feb 2009 07:37:24 -0800 (PST)

Nicolas Pitre <[email-masked]> writes:
> On Sun, 22 Feb 2009, Miklos Vajna wrote: 
> > On Mon, Feb 23, 2009 at 01:28:33AM +0530, Rohan Dhruva <[email-masked]> wrote:

> > > That being said, I have knowledge of C/C++ what was taught to me in
> > > school and college. I realize that my qualifications as such are not
> > > very impressive, and hence I wish to start with a smaller project. I
> > > read on the http://git.or.cz/gitwiki/SoC2009Ideas page that a
> > > "jump-in" project might be the "Restartable Clones" proposal.
> > 
> > I would recommend you to read this thread:
> > 
> > http://thread.gmane.org/gmane.comp.version-control.git/55254/focus=55298
> > 
> > Especially Shawn's message, which can be a base for your proposal, if
> > you want to work in this.
> 
> I don't particularly agree with Shawn's proposal.  Reliance on a stable 
> sorting on the server side is too fragile, restrictive and cumbersome.
> 
> Restartable clone is _hard_.  Even I who has quite a bit of knowledge in 
> the affected area didn't find a satisfactory solution yet.

I think it is possible for dumb protocols (using commit walkers) and
for (deprecated) rsync.
 
The only thing would be for "git clone --continue" to bypass check if
directory to download repository to is nonexistent or empty.  

I guess that what code can do (or perhaps even does currently) for
commit walk based dumb protocols (like HTTP) is to do commit walk, and
for packfiles which are already downloaded or partially downloaded,
download rest of file (if web server supports it; if not, redownload
whole packfile, but do not redownload already exiting packfiles).

For rsync:// it could be enough to just bypass the check... but the
probability of getting corrupted repository would be even higher,
unfortunately.

> I think restartable clone is a really bad suggestion for SOC students.  
> After all we want successful SOC projects, not ones that even core git 
> developers did not yet find a good solution for.
> 
> IMHO of course.

But I agree that within current limits (as far as I know there are no
way to ask for SHA-1; you can only ask for refs for security reasons)
it would be difficult to very difficult to add restartable clone
support to native (smart) protocols.

If not for this limitation it would be, I think, possible to do a kind
of fsck, checking which commits in packfile are complete (i.e. have
all objects), and based on that ask for subset of objects.  This would
require support only from a client... alas, this is not possible.

In mentioned post Shawn talks about a way for server to 1) generate
exactly the same packfile (the proposal is to replay want/have, but it
also requires stable sorting of objects); 2) transfer only the rest of
file (but server has to regenerate packfile anyway, as packfiles are
generated on-the-fly; well, unless it caches packfiles, which might be
good idea anyway).

I think that unless 'restartable clone' is limited to commit wakers
(HTP protocol etc.) it should be moved up the diffuculty from "New to
Git?" section. I guess that mirror-sync, formerly GitTorrent, could be
easier to implement.

-- 
Jakub Narebski
Poland
ShadeHawk on #git