On Tue, 17 Oct 2006, Jakub Narebski wrote: > > rewrites the part of your working tree that actually changed, so switching > > is extremely efficient even with a large repo. > > Unless you have branch(es) with totally different contents, like git.git > 'todo' branch. Yes. I have to say, that's likely a fairly odd case, and I wouldn't be surprised if other VCS's don't support that mode of operation at _all_. The fact that git branches can be independent of each other is very natural in the git world, but > > So there is seldom any real need or reason to actually have multiple > > checkouts. But it certainly _works_. > > But without .git being either symlink, or .git/.gitdir "symref"-link, > you have to remember what to ser GIT_DIR to, or parameter for --git-dir > option. I'd strongly suggest that people who do this should actually do git clone -l instead of actually playing games with symlinking .git/ itself or using GIT_DIR. It means that the two checkouts get separate branch namespaces, but that's really what you'd want most of the time. You _can_ share the whole branch namespace and do the symlink of .git (or just set GIT_DIR - but that's pretty inconvenient), and it might end up being "closer" to what some other VCS would do. But the natural thing to do with git is to just share some of the objects through local "slaving" of the repositories, and consider them otherwise entirely independent. 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