Matthias Lederhofer <matled@xxxxxxx> 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? - 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