On Wed, 23 Apr 2008, Junio C Hamano wrote: > *1* In that sense, a more sensible order than rewriting "clone" in C in > its current form would be to make necessary enhancements to the components > in this sequence that need to implement clone, figure out how they should > fit together and first make "clone" a four-liner shell script. Then > rewriting the result in C may become more trivial. clone can't be a four-liner shell script, because it has to come up with the name of the working directory for a non-bare clone, which doesn't make sense for any other program. Currently, a local clone is special in that it duplicates all of the objects without checking whether the destination already has them (because it can't have anything) or whether they're actually needed; fetch could do some similar stuff, but couldn't do quite that much optimization, because it's not likely the same special case. Something needs to get the code to figure out the remote HEAD, and it shouldn't be "remote" for clone's use, because then clone would take an extra connection, since "fetch" obviously has to connect and "remote" would run before it and in a separate process. It also needs to support --reference (list another repository's refs as your refs, because you have that repository as an alternate but don't have your own refs that use its objects), which is sort of plausible for fetch but much less useful. Aside from that, it's obviously got quite a few lines of option parsing to get the right arguments to the things it calls, as well as determining whether to check out a branch (depending on what we did with the origin) and such. -Daniel *This .sig left intentionally blank* -- 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
