Hi, On Fri, 9 Jan 2009, Junio C Hamano wrote: > I think we lost the alternate object store support when git-fetch was > rewritten from the original shell script (that did support fetching from > such a repository over rsync:// transport) to a reimplementation in C, > with commit b888d61 (Make fetch a builtin, 2007-09-10). > > Later, cd547b4 (fetch/push: readd rsync support, 2007-10-01) attempted to > resurrect some rsync support (b888d61 lost rsync support completely for > git-fetch), but introduced these lines in transport.c: > > /* NEEDSWORK: handle one level of alternates */ > result = run_command(&rsync); Indeed... And I know who's responsible for those lines. However, I am swamped with work these days, and my Git time budget was _way_ overspent what with the recent patches. So whoever would like to give it a go, go wild. This is actually a very fine opportunity for people to get involved who always wanted to; it is a relatively low-hanging fruit. It should just be a matter of getting objects/info/alternates (one can easily reuse a large part of the args[] array filled before the quoted code) into a temporary file. If that does not succeed, return 0, otherwise fetch those objects, too (again reusing most of the args[] array). It is that easy because objects as well as packs are immutable, so we can just build the union of objects/packs from the remote and its alternate. Then all which is left to do is to add a test case to t/t5510-fetch.sh, and you're set. As there are already test cases for rsync:// in it, it should be as simple as putting an empty file into a newly created directory, create an alternate for the "remote" pointing to the directory, fetching, and testing that the empty file was copied. That's possible because rsync:// is dumb and does not verify the files it copied. Oh, and don't forget to remove the NEEDSWORK comment :-) And now I'm curious who's up for it... Ciao, Dscho -- 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
