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

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

On Thu, 31 Jul 2008, Björn Steinbrink wrote:
> > 
> > So literally, if you do
> > 
> > 	git clone <cntral-repo-over-network> <local>
> 
> Hum, I guess I'm just missing something and prepare to get flamed, but
> wouldn't you want that one to be bare? Otherwise, the other clones won't
> see all of the original repo's branches, right?

Making it bare might be a good idea for other reasons too (it makes it 
much more obvious that it's a "local clone" and is somehow special). But 
it's really a matter of taste - and the project - exactly how you do it. 

For example, the kernel only has a single master branch in the top repo, 
so there it really doesn't matter, and yes, I'm more kernel-oriented than 
anything else, of course.

But I don't think it's exactly wrong to have the initial clone be a real 
repository that you do work in. Quite often the history really is the 
_bulk_ of the database by far (at least with projects that have big enough 
repositories for this to even matter in the first place!), and as long as 
you just download that once and share that thing, you're already ahead of 
the game and the rest is really just details.

> Maybe even better:
> 
> mkdir local-mirror
> cd local-mirror
> git --bare init
> git remote add -f --mirror origin <central-repo-over-network>
> 
> A cronjob (or whatever) could keep the local mirror up-to-date and the
> other repos can fetch from there.

Heh. You can certainly do it many ways. I suspect the _easiest_ model is 
actually to do one single local repo that is special (and perhaps bare), 
and then you can clone all the other ones with

	git clone --reference <local-reference> <remote> <new-local>

because that will automatically set up the new local repo to have the 
local reference as an alternates thing, and will avoid downloading 
unnecessary stuff.

So my point about the eleven repos was not that it's the best way to do 
one remote clone and then eleven local ones - my point was that even if 
you do that _stupid_ thing, you'd have seen sharing without even knowing 
what you really did.

If you want to explicitly share, I think the local bare reference and 
using "git clone --reference" is the best way. It sets up a special 
link-file (it's just a text-file that git knows about, so it should work 
fine under Windows too - no need for filesystem support) in 
.git/objects/info/alternates.

IOW, git-clone --reference works like "git clone -s", but does so with one 
special local database, while allowing you to clone from anywhere. Very 
convenient.

And no, I don't think we document all these "tricks" very well. Partly 
because people are _already_ complaining about how git can do so many 
things ;) But partly because if you don't know what you're doing, the 
"tricks" are often things you really need to understand, and can be a bit 
dangerous otherwise.

For example, the "git clone -s" (or --reference) thing is *very* useful, 
but one result of other repositories then sharing a database with the 
reference one is that suddenly the reference repo is very special. You 
must not remove it (obviously!), but you also must not rebase it and prune 
it etc.

So all the normal git workflows are at least designed to be _safe_ even in 
the absense of people not knowing what they are doing. The duplication may 
be using harddisk space, but

 - quite often the checkout is actually an even bigger issue, and the git 
   repo is small enough that lots of people don't really worry.

 - duplicating the repo also means that you cannot _possibly_ screw up 
   other people/repos and does give you a kind of backup (even if 
   same-disk backups are obviously of dubious use: they shouldn't be your 
   _primary_ backup, but having multiple copies on a single disk still 
   protects against a _lot_ of problems)

so... It's a trade-off.

			Linus