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
Attachment:
signature.asc
Description: OpenPGP digital signature
