# Re: [PATCHv2] Possibility to read both from ~/.gitconfig and from $XDG_CONFIG_HOME/git/config

1 messages from 2012-05-31 to 2012-05-31. Participants: nguyenhu@minatec.inpg.fr.
Thread: https://gitlist.dev/t/30667

## nguyenhu@minatec.inpg.fr, 2012-05-31 08:46

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>
URL: https://gitlist.dev/e/20120531104634.Horde.MtY_VHwdC4BPxy-qPK1XmXA%40webmail.minatec.grenoble-inp.fr

```

Junio C Hamano <gitster@pobox.com> 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@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.

```