On Sat, 10 Mar 2007, Junio C Hamano wrote:
> Matthias Lederhofer <matled@xxxxxxx> 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:
> 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
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html