On Tue, 17 Oct 2006, Jakub Narebski wrote:
quoted text
> > 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 

quoted text
> > 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@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html