Re: Multiple working trees with GIT ?

[Willy Tarreau <w@1wt.eu>]

On Thu, Jan 24, 2008 at 01:38:45PM +0000, Johannes Schindelin wrote:
> Hi,
> 
> On Thu, 24 Jan 2008, Willy Tarreau wrote:
> 
> > On Thu, Jan 24, 2008 at 11:04:42AM +0000, Johannes Schindelin wrote:
> > 
> > > On Thu, 24 Jan 2008, Julian Phillips wrote:
> > > 
> > > > 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.
> > >
> > > > 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