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

On Thu, 31 Jul 2008, Björn Steinbrink wrote:

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.

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