Miklos Vajna <vmiklos@xxxxxxxxxxxxxx> writes: > This is like GIT_CONFIG but it is not read instead of .git/config, but > in addtition to it. > > Signed-off-by: Miklos Vajna <vmiklos@xxxxxxxxxxxxxx> > --- > > On Fri, Dec 18, 2009 at 11:54:32PM +0100, Moe <moe@xxxxxxxxxxxxxx> wrote: >> $GIT_CONFIG doesn't work for this purpose because when set >> git will *only* read the referenced file and ignore the >> repository settings. > > What about this? The patch text itself may be fine, in the sense that it makes "we read from three" to "we now read from four", but I am not impressed. I find the original use case highly moronic. For people to be sharing an account, hence $HOME, there must be a reason. They want to (rather, the administrator wants them to) use a common shared set of settings, so $HOME/.gitconfig should be shared among them, just like $HOME/.emacs and $HOME/.login are, unless there is some strong reason to treat .gitconfig any differently from all the other $HOME/.whatever files. But I don't think there wasn't any argument to defend that. That makes the patch doubly suspect and throws it into "because we can", not "because we should". Wouldn't it be just a matter of giving different HOME after they log-in? After all, Moe will be giving _some_ way to his users set different value to GIT_CONFIG_EXTRA depending on who they really are, and that same mechanism should be usable to set different HOME to them, no? As $HOME/.gitconfig is relative to the value of that environment variable, I don't see a reason for us to fall into this "three is not enough, but when we add another, we are fine" attitude, which makes me suspect that there is something fundamentally wrong there. -- 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