From: Junio C Hamano <hidden> Date: 2016-06-15 22:42:59
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?
From: Andy Parkins <hidden> Date: 2016-06-15 22:42:59
On Sunday 2007, March 11, Junio C Hamano wrote:
What's the real motivation behind all this?
Coincidentally, I found I was needing this feature just yesterday.
I wanted to keep random configuration files in a repository. I didn't
want the directory structure though. The config files are, of course,
in my home directory, however I didn't want the danger of putting
a .git that low in my hierarchy. Having a .git that is findable from
any location in my tree seems a bad idea.
So; I put the repository somewhere else and set GIT_DIR. However that
scuppered my plans. Trying to add a config file results in "not in a
working directory" (of course), because even though git can find the
repository, it has no way of knowing which directory to consider as the
root of the working tree.
Let me put this in command form for you:
$ cd $HOME
$ export GIT_DIR=$HOME/gitrepos
$ git init
$ git add .bashrc
fatal: add must be run in a work tree
Being able to set GIT_WORKING_DIR would have let me do this.
Andy
--
Dr Andy Parkins, M Eng (hons), MIET
andyparkins@gmail.com
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.
For example have the checkout of a git repository publicly available
(e.g. on a webserver). The .git directory containing all the history
should probably not go there (especially if it tracks scripts). Sure,
setting strict permissions solves this too in most cases but anyway
it's nice to have the option to move the repository away.
Additionally when reading the man page about GIT_DIR it says 'the
default value is .git', which sounds a bit like "hey, if you don't
like the name you're free to change it", but as soon as you change it
you run into problems because git behaves strange in subdirectories :)
But either .git/work_dir or a configuration means you are
linking a repository with a _single_ working tree, permanently.
Well, this would only be the default value for convenience with
GIT_WORK_DIR/--work-dir still overriding this value. You'd only have
to set GIT_DIR=~/src/website and work on the website without setting
the second environment variable too.
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?
The tools to inspect (git diff, ..) and track (git add, ..) work fine.
So one could easily (without copying stuff around) track changes of a
read-only directory.
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