Re: Summer of Code project ideas due this Friday
- From
Sam Vilain <sam@vilain.net>
- Date
- Mar 11, 2011, 22:42 UTC
- Message-ID
- <4D7AA545.4050006@vilain.net>
- In-Reply-To
- <AANLkTinKnfiE9zQwYxfCX8VhRfgJhQopDbqBA+oQLL0w@mail.gmail.com>
On 12/03/11 03:27, Nguyen Thai Ngoc Duy wrote:
Show 27 quoted lines
> On Fri, Mar 11, 2011 at 9:10 PM, Alexander Miseler <alexander@miseler.de> wrote: >> This may all be aiming to short. IMHO the best solution would be some >> generic way for the client to specify exactly what it wants to get and to >> get just that. > But how do you define "what it wants to get"? Pros and cons are > different and depend on that defintion. > > Git's way of saying now is "I have these commits, give me these > branches (cutting at certain depth)". A near future extension would be > "I have these commits _restricted to these paths only_, give me...". > If it's broken half way, start again. > > The bundle way is basically Git's way except that the remote side says > "I've got this bundle, fetch it here, then you can ask us again for > the rest in a normal way". > > mirrorsync (aka gittorrent) says "I have this commit, give me objects > so that I can have this commit", which leaves the (probably) huge > initial commit out of view. > > My way is "give me a chain of deltas starting from this SHA-1". A big > blob can be considered as a history of smaller pieces. > > The last way of saying is just "give me this object", which would be a > big waste of bandwidth. > > Your move :)
Just FWIW, I recently produced some diagrams and demonstrated the resumable clone algorithm; speed is currently very limited by the implementation at 15 minutes to slice up git.git; but I'm playing with libgit2 to see if I can make a more optimal version.
See http://vilain.net/comp/git/gittorrent/commit_reel.html
Sam