On 30/07/14 17:45, Matthieu Moy wrote:
> Tanay Abhra <tanay...@gmail.com> writes:
>> Also, any thoughts on what to do with git_default_config()? We can,
>> 1> make a new function git_load_default_config(), use it for the rewrites.
> That seems the most sensible option. It could be called it git.c before
> the command-dependant part, so that any call to git loads this.
> I didn't check if it was correct (e.g. do some command rely on the fact
> that the default config is not loaded?)

Hmm, here be dragons ... :-P

I don't know that there has actually been any kind of policy
regarding the reading of config files/variables in git (or if
there is a different policy for plumbing vs porcelain), but it
has always seemed to be somewhat ad-hoc; each command decides
for itself what it wants to read.

However, with increased use of common code which _uses_ certain
config variables for correct operation, the 'choice' is much
harder to make (and may change after the fact!).

For example, about a year ago I submitted a couple of patches
which added a call to git_config(git_default_config, NULL) to
both 'git pack-refs' and 'git show-refs'. This was as a result
of the 'mh/ref-races' branch which introduced a 'stat_validity'
api for checking if the packed-refs file had changed on the
filesystem since last you looked. This re-used some of the same
code used to handle index updates that used config variables
like core.checkstat and core.trustctime. These config variables
can affect the correctness and/or the efficiency of the code on
some platforms (e.g. cygwin, mingw).

[Note: 'stat_validity' has since been re-used again (why not?)
in some shallow clone code, so similar comments may apply ...
I haven't looked.]

However, those patches were dropped, because it resulted in an
(unwanted) change in behaviour. In particular, 'git show-refs'
changed behaviour because it now 'listened' to core.abbrev!

I started to look at splitting the 'core config variables' into
two groups; essential variables that _all_ git commands should
read for correct/efficient/consistent behaviour and everything
else (mainly UI related variables).

However, something else came up ...

Just an FYI.

Ramsay Jones

To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to