From: nguyenhu@minatec.inpg.fr Date: Thu, 31 May 2012 08:46:34 GMT Subject: Re: [PATCHv2] Possibility to read both from ~/.gitconfig and from $XDG_CONFIG_HOME/git/config Message-ID: <20120531104634.Horde.MtY_VHwdC4BPxy-qPK1XmXA@webmail.minatec.grenoble-inp.fr> Junio C Hamano 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 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.