Matthias Lederhofer <matled@xxxxxxx> writes: > 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. That's fine. Will you constantly work inside that webserver exposed working tree, though? I suspect the operation you would do there would only be "GIT_DIR=/some/where/else git checkout -f" to refresh the published copy, so I do not think even GIT_WORK_DIR is needed for that use case (just to make sure, I am not opposed to having GIT_WORK_DIR -- my "why bother" is about having the equivalent in .git/work_dir or .git/config). > 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 :) That is really a historical mention. The current Porcelain-ish depend on that "default" layout (I know you know that after seeing what setup_git_directory does), and I think GIT_DIR should not be taught to new people as such. > 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. Why does read-only directory have changes to begin with??? - 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