Re: [RFC] introduce GIT_WORK_DIR environment variable

On Sat, 10 Mar 2007, Junio C Hamano wrote:

Matthias Lederhofer [off-list ref] writes:

quoted

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.

I actually like this feature. Let me explain why I think it's a great 
feature:

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?

I'll tell you why: it makes tons of sense to have the git repository 
linked to exactly one working tree, *but the reverse is not necessarily 
always true*!

In other words, it can be a 1:n relationship.

You can have one working tree that is related to *multiple* git 
repositories.

That sounds insane, but I actually think it works, and makes tons of 
sense. Think something as simple as your own home directory.

It's possible that you want to track your music collection with git, but 
say that your music collection is a few different subdirectories or files 
in your home directory: maybe you track your "Music" directory (which 
contains the actual mp3 files or whatever), but maybe you'd like the same 
repository to *also* track things like your configuration file for 
whatever mp3-player you're using (".xmms"? Whatever).

So let's say that you have a git repository for tracking all that. The 
"working tree" for that git repository would be your home directory.

Now, imagine that you *also* want to track something else in git, that you 
*also* have in your home directory. Say your ".bashrc" files etc. They 
have nothing to do with your music tracking setup, so you don't want to 
track it in the same git repository, and you want to have a totally 
different .git/index file for those. But again, the *working*tree* is 
actually your home directory.

So allowing you to set the working tree associated with a particular git 
repository actually solves that problem. They can both share the same 
working tree (you'd want to track disjunct parts of the working tree, of 
course), which means that the working tree obviously does *not* want to 
have a .git/ directory in it. And to track your music changes, you'd just 
do

	cd music-repository
	git add music/
	git commit

to add any new files, and you'd be all set (or something like this).

There are other cases than just your home directory where you might want 
to track disjoint filesets in different git repositories. Things like /etc 
fall under the same "many unrelated things in the same working tree" 
setup.

So I actually think it makes tons of sense to allow a way to set the 
working tree for a git repository, and go the other way.

		Linus