
Introducing Git fastclone - hepha1979
https://corner.squareup.com/2015/11/fastclone.html
======
eropple
Related but not identical: dealing with forests of submodules is proving to be
a pretty monumental pain. Is there some nice gadget out there I'm not familiar
with (maybe like the Android 'repo' tool but less 'aaaaaah please make it
stop') to help manage active development across many git repos with
submodules?

~~~
emmelaich
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/](http://myrepos.branchable.com/)

------
weitzj
You should also check out

[https://github.com/orrc/git-webhook-proxy](https://github.com/orrc/git-
webhook-proxy) [https://www.cloudbees.com/blog/advanced-git-
jenkins](https://www.cloudbees.com/blog/advanced-git-jenkins)

------
johnkeeping
How does this compare to git-worktree (added to core Git in 2.5)?

~~~
gnoway
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.

