On Wed, Sep 18, 2013 at 9:30 PM, David Aguilar <dav...@gmail.com> wrote:
>>On Wed, Sep 18, 2013 at 1:13 PM, David Aguilar <dav...@gmail.com> wrote:
>>> Will this not conflict with folks that supply their own gitconfig?
>> You mean people that provide their own ETC_GITCONFIG? If you mean
> distributions, their packaging would override /etc/gitconfig, if you
> mean people that have already a /etc/gitconfig, packaging systems
> usually save the old one so they can solve the conflict manually (e.g.
> /etc/gitconfig.pacsave). So no, it would not conflict.
> Yuck. Yes, that one. I package my own /etc/gitconfig (as we have long
> advertised as the "way to do it")
You package /etc/gitconfig *outside* the git package? I don't see how
that could have been ever advertised as the way to do it.
> and asking users to manually fix up thousands of machines is a bad idea.
Users don't package /etc/gitconfig outside git.
>>> I like the idea. Docs? Also, should this not be done in the C side so that
>>> we don't waste time reading the config, and also prevent users from
>>> overriding these?
>> But we want them to be easily readable, and possibly allow
> distributions to easily modify them.
> In that case I take it back -- I dont like that approach. We want
> consistency, not divergence. This encourages the former.
So you think we have more consistency right now? We don't even have a
predefined /etc/gitconfig, that creates more inconsistency, as
everybody's configs and aliases are very very different.
This patch would definitely make things more consistent.
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