Junio C Hamano <gitster@pobox.com> wrote:
Show 9 quoted lines
> Is it just me who finds the above three lines extremely unreadable? > > Also can you give this patch a bit more sensible title? > "Possibility to" does not tell us much---anything is possible if you > change code after all. > > I see the patch does not touch the writing codepath, which is > probably a good thing, but the log message should explicitly state > that.
I will change that in my next version.
Show 7 quoted lines
> I am not sure in what way $HOME/.gitconfig has "priority". > > Your proposed log message says that You read from $HOME/.gitconfig > and then from $XDG_CONFIG_HOME/git/config, which means that any > single-valued variable set in $HOME/.gitconfig will be overwritten > by whatever is in $XDG_CONFIG_HOME/git/config, no? That sounds like > you are giving priority to the latter to me.
You are right. Git takes into account $HOME/.gitconfig if one variable is defined in both configuration files. I will explains that more clearly in documentation.
Show 6 quoted lines
> The original that read from $HOME/.gitconfig was simple enough so
> having three copies of getenv("HOME") was perfectly fine, but as you
> are introduce this much complexity to to decide which two files to
> read from, the code added this patch needs to be refactored and
> three copies of the same logic need to be consolidated, I would have
> to say.Matthieu Moy <Matthieu.Moy@grenoble-inp.fr> writes:
> Shouldn't there be a helper function to get the path ~/.config/git/ > and then append config? You're already computing this path twice, and > we'll need more instances of it if we want to give default values to > core.excludesfile and core.attributesfile in this directory too.
I agree. I will write a function to get ~/.config/git/ and refactor code.