Nicolas Pitre <nico@xxxxxxx> writes: > On Sun, 22 Feb 2009, Miklos Vajna wrote: > > On Mon, Feb 23, 2009 at 01:28:33AM +0530, Rohan Dhruva <rohandhruva@xxxxxxxxx> 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 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
