On Sun, Aug 24, 2008 at 11:11:14AM -0700, Junio C Hamano wrote: > Consistency and usefulness are different things. Suppose you want as the > upstream of your project maintain and distribute a mail-alias list in-tree > (say, the file is at the root level, CONTRIBUTORS), and you suggest > contributors to use it when using "commit --author". > > Which one do you want to write in your README: > > [user] > nicknamelistfile = ../CONTRIBUTORS > > or > > [user] > nicknamelistfile = CONTRIBUTORS > > You have to say the former if it is relative to .git/config. Couldn't the exact opposite argument be made for "suppose you want to put the mail-alias file in a repo-specific directory that was not tracked?" I.e., you are trading off "CONTRIBUTORS" against ".git/CONTRIBUTORS". So which one inconveniences the smallest number of people is really a question of what people want to do with such pointers (and since we don't support any yet, we don't really know...). But more worrisome to me is that the working directory and git directory do not necessarily follow a "../" and ".git/" relationship. How would you resolve "../foo" with: GIT_DIR=/path/to/other/place git ... or git --work-tree=/path/to/other/place ? If you want to be able to point to either, I suspect we are better off simply introducing some basic substitutions like $GIT_DIR and $GIT_WORK_TREE. Maybe even just allow environment variable expansion, and then promise to set those variables, which takes care of $HOME automagically. -Peff -- 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
