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

[Linus Torvalds <torvalds@linux-foundation.org>]

On Thu, 31 Jul 2008, Craig L. Ching wrote:
> 
> We find ourselves constantly having to shift gears and work on other
> things in the middle of whatever it is we're currently working on.  For
> instance, in the scenario above, A might be branch that contains a
> feature going into our next release.  B might be a bugfix and takes
> priority over A, so you have to leave A as-is and start work on B.  When
> I come back to work on A, I have to rebuild A to continue working, and
> that's just too expensive for us.  So we use the monotone-like
> new-workdir which allows us to save those build artifacts.
> 
> So, that said, I ask again, am I missing something?  Is there a better
> way to do this?  How do the kernel developers do this, surely they're
> switching branches back and forth having to build in-between?

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

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).

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.

Junio?

		Linus