Junio C Hamano <junkio@xxxxxxx> writes: > I am not quite sure how $GIT_CONFIG and $GIT_CONFIG_LOCAL were > meant to be used. Are there any *real* users? With lack of > information on the intended uses of these two environment > variables, I hacked up the following tweaks on top of the above > defined semantics, to imitate what I _think_ was the original > intention. The hacked one goes like this: > > - $GIT_CONFIG environment, if set, names a file to be read > first. We read it first. > > - If $GIT_CONFIG is unset, then $GIT_CONFIG_SYSTEM (or > /etc/gitconfig) and $HOME/.gitconfig are read, as above. > > - Next file to be read is $GIT_CONFIG_LOCAL (if set) or > $GIT_DIR/config. When reading this file, if we read from > $GIT_CONFIG earlier, we read only "core.*" section from it. > ... Addendum. Judging from the way builtin-config.c::get_value() uses it, I think whoever invented $GIT_CONFIG_LOCAL as a parallel to $GIT_INDEX_FILE and $GIT_OBJECT_DIRECTORY, in other words, what usually appear under $GIT_DIR can be placed somewhere completely different. So I think the above "hack" I described still honors its intended use. I am still not sure what good GIT_CONFIG would be to completely override everything else, though. - 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