RE: Monotone workflow compared to Git workflow ( was RE: Git vs Monotone)

From: Linus Torvalds [mailto:torvalds@linux-foundation.org] 
Sent: Thursday, July 31, 2008 3:09 PM

Sure, if you want to keep the build tree around, you would 
probably not use branches. 

I think we'd still use branches, but we just need to isolate their
workdirs from each other.

But yes, then you'd likely do "git clone -s" with some single 
"common point" or use "git worktree". And even if you don't 
use "-s", you should _still_ effectively share at least all 
the old history (which tends to be the bulk) thanks to even a 
default "git clone" will just hardlink the pack-files.

So literally, if you do

	git clone <cntral-repo-over-network> <local>

and then do

	git clone <local> <otherlocal>
	git clone <local> <thirdlocal>

then all of those will all share the initial pack-file 
on-disk. Try it.

(You may then want to edit the "origin" branch info in the 
.git/config to point to the network one etc, of course).

Yes, thank you for the explanation.  Having used git a fair amount now,
that makes perfect sense to me, in fact, it sounds a lot like
git-new-workdir, but I think I'll change our use of git-new-workdir to
something more "core" git.  It seems to me that maybe this is something
that could be documented more prominently?  Or maybe it is and I've just
missed it.  This would have saved me a lot of time originally to be
sure.

Oh, and to make sure I'm not lying I actually did test this, 
but I also noticed that "git clone" no longer marks the 
initial pack-file with "keep", so it looks like "git gc" will 
then break the link. That's sad. I wonder when that changed, 
or maybe I'm just confused and it never did.

What's the consequence of that then?  Because of that, would you say
"don't gc your master local repo until all derived repos are merged?"
If that link is broken is it just a loss of space? Or is it more?

		Linus

Thanks again!

Cheers,
Craig