Re: [RFC] introduce GIT_WORK_DIR environment variable

From: Linus Torvalds <torvalds@linux-foundation.org>
Date: Mar 11, 2007, 20:37 UTC
Message-ID: <Pine.LNX.4.64.0703111326170.9690@woody.linux-foundation.org>
In-Reply-To: <7vabykxs15.fsf@assigned-by-dhcp.cox.net>

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

Show 12 quoted lines

> Matthias Lederhofer <matled@gmx.net> writes:
> > 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:

Show 5 quoted lines

> 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