>> The new-workdir feature doesn't *have* to be about symlinked
>> .git/ metainfo space, but could also be about symref'ed .git/
>> metainfo. (A discussion was done in 2005s "Getting rid of
>> symlinks in .git?", but the conclusion was that it would slow it
>> down too much? *ponder*)
> 
> Symref'ed isn't really the right term ... we're not talking about
> refs here.  You would have to basically implement symlinks _inside_
> git ...

Yes, sorry for mixing up the terms here.

> New-workdir really _is_ all about symlinks.  It already exists as a
>  contrib feature - and moving it into core is (as I understand it)
> really just moving it, not redesigning.

Yes, if simply moving into is core is good enough. IMHO since its 
based largely on FS symlinks it needs a slight redesign before it can 
be moved into core to make it platform agnostic. If not, it should 
remain contrib [again, IMHO].

> If you were going to avoid symlinks, then probably the cleanest way
> would be to have an explict way to point at the actual repo -
> rather than making the working look like a repo if you squint hard
> enough.  Which sounds rather like it would be an extension to
> GIT_DIR + GIT_WORK_TREE.  I haven't looked at it, but it shouldn't
> be too hard to have a mechanism that automatically does
> GIT_DIR=<there> GIT_WORK_TREE==<here> when the appropriate setup is
> in place?  Though you would have to get it into all the appropriate
> places ...

*nod*

-- 
.marius