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 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
