Re: Multiple working trees with GIT ?

On Thu, Jan 24, 2008 at 01:38:45PM +0000, Johannes Schindelin wrote:

Hi,

On Thu, 24 Jan 2008, Willy Tarreau wrote:

quoted

On Thu, Jan 24, 2008 at 11:04:42AM +0000, Johannes Schindelin wrote:

quoted

On Thu, 24 Jan 2008, Julian Phillips wrote:

quoted

You might want to have a look at the git-new-workdir script in 
contrib, it does basically the same thing.  It's been there for 
about 10 months now. It was based on an email from Junio:

http://article.gmane.org/gmane.comp.version-control.git/41513/

FWIW I have a patch to do something like that in "git branch" itself.

quoted

However, there are some caveats about using this approach, basically 
about the fact that there is nothing stopping you from updating refs 
that are currently checked out in another directory and causing 
yourself all sorts of pain ... the topic has cropped up a couple of 
times on the list since the script was added.

I agree; maybe we should have a telltale file 
"refs/heads/<bla>.checkedout" which is heeded by "git checkout" and 
"git branch -d/-D", as well as update_ref() (should only update that 
ref when it HEAD points to it)?

Why not generalize this into HEAD.$branch (thus limiting to one checkout 
per branch) or HEAD.$checkoutdir ?

Because multiple working trees for the same repository will always be a 
second-class citizen.  And I would rather not affect the common case too 
much.

OK.

Having a "lock" file which is heeded by just a few places which are 
supposed to update refs (thinking about it, just update_ref() should be 
enough), is at least a well-contained change.

indeed, with the appropriate warnings/error messages, that makes a lot of sense.

Cheers,
Willy