Thread (1 message) 1 message, 1 author, 2016-06-15

Re: [PATCH] check_repository_format_version(): run git_default_config() again

From: Junio C Hamano <hidden>
Date: 2016-06-15 22:43:27

Junio C Hamano [off-list ref] writes:
Sorry, I do not understand this patch from the commit log
description.

In the old days in 1.5.2 before either implementation of
work-tree stuff, this function never called git_default_config()
and presumably "git log" worked as expected for Brian.  Why is
this call needed _here_, not in some of the callers?
Sorry scratch that.  v1.5.2 did not even have core.pager.

I see git_config(git_default_config) is called from
setup_git_directory_gently() in the version that introduced
core.pager.  Curiously enough it does the config twice, once
where no GIT_DIR is set and it sets inside_work_tree, and
another by calling git_config(git_setup_config) -- big thanks
for sorting this mess out.

I however have a mild suspicion that this has to be done much
earlier.

For example, "git -p log" would first call handle_options(),
which calls the setup_pager() logic, and then we call
handle_internal_command() which calls setup_git_directory() that
eventually leads to the callchain of finding the .git directory
and .git/config file to be used.  In that case, when we make the
call to setup_pager() from handle_options(), we haven't even
figured out if there is a configuration file, let alone reading
from it.

We could work this around by having the "we need config -- where
is it" logic in setup_pager(), but if we later have new options
like -p that affects the way how git wrapper itself behaves
based on the configuration, we would need the same "early config
read" logic to support it.
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help