Junio C Hamano <gitster@xxxxxxxxx> wrote:
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.
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.
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@xxxxxxxxxxxxxxx> 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.
--
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