Re: [RFC] introduce GIT_WORK_DIR environment variable

Matthias Lederhofer [off-list ref] writes:

Missing:
Documentation update but if this feature should not get accepted..
therefore I'll wait for feedback first.

Did I say something about a comment like this in the past?  But
I'll let this pass this time...

Idea:
Add some way to configure tho working directory for one repository
and set GIT_WORK_DIR automatically when GIT_DIR is used.  I think of:
 * a subdirectory in the repository directory
   e.g. .git/work_dir which is supposed to be a symlink (or a textfile
   containing the path for windows compatibility?)
or
 * a configuration variable

I am not sure why you bother.  Obviously I am missing a few
useful use cases you and Nguyen have in mind.

One very typical use of GIT_DIR to have the repository somewhere
other than the usual $GIT_TOP_DIR/.git is to do an initial
import from an extracted tarball into a bare repository (and
then wipe away the temporary directory that contains extracted
tarball), and that use case I understand well.

But either .git/work_dir or a configuration means you are
linking a repository with a _single_ working tree, permanently.
If you are permanently linking one repository with a _single_
working tree, is it too much bother to have that repository at
the usual $GIT_TOP_DIR/.git like everybody else?

If storage space is the issue, then doing

	$ln -s $else_where/.git .git

would be sufficient.

What's the real motivation behind all this?  

I've heard read-only working tree in the past, but that cannot
be it.  If the working tree is read-only and if you are telling
git to always use that read-only working tree when using that
particular repository, what useful git operations are you doing
while in that working tree?