Introducing Git fastclone

Agree, I used submodules because I have to, but I've heard git subtree is a good option.

There's also `mr` - multirepo from Joey Hess,the creator of git annex'

http://myrepos.branchable.com/

fastclone uses reference cloning, which references objects from another clone but pulls missing stuff from origin. There are two local object stores, the reference clone and the referenced clone. Cloning semantics are identical to a regular clone, it's just 'git fastclone' instead of 'git clone', presumably without some of the standard options like --reference, --shared, --shallow, etc.

worktree appears to do away with the extra complication; it's just another working tree off the same base clone. There's a single object store. You have two commands to deal with, 'git clone' and 'git worktree'.

I think that both can be used for the same purposes and yield similar results, but fastclone is targeted at the automated build scenario whereas worktree is more developer-focused. In an automated build environment with an m:n relationship between repos and builds, I think worktree would be more complicated because you'd have to handle the 'clone vs. worktree' decision yourself. It's also apparently not great w/ submodules yet; fastclone claims to handle submodules.

Fastclone is another attempt to deal with the distributed-ness of git in a scenario where you don't want or need local copies of the objects, just the working tree. We fight with this at my company; we like git, and it does some nice things, but our use case is really better suited to a centralized vcs. For people looking at fastclone, etc. - consider that maybe you don't really want a dvcs in the first place.