Michael Haggerty writes:
> You make an interesting point: values that start as a list of
> independent booleans can grow dependencies over time.
>
> In retrospect, ISTM that a better interface for the indentation-related
> "whitespace" settings would have been something like
>
> * "whitespace.ind
Jeff King writes:
I didn't reply to the latter part of this message yesterday, because
I wanted to think more on it.
> But is it such a bad thing to have them in conflict? Can't we define a
> set of rules that does what people expects? For example, by the "last
> one wins" principle, any time we
Hi,
On 2015-02-01 23:34, Junio C Hamano wrote:
> Jeff King writes:
>
>> 1. I'm a user who has set my preferred core.whitespace in my
>> ~/.gitconfig. A particular project I am working on uses an
>> alternate tabwidth. How do I set that in the repo config without
>> repeating my
Junio,
Thanks for your thoughtful response.
On 02/01/2015 09:18 PM, Junio C Hamano wrote:
> Michael Haggerty writes:
>
>> On 01/28/2015 11:33 PM, Junio C Hamano wrote:
>>> + When choosing the variable namespace, do not use variable name for
>>> + specifying possibly unbounded set of things,
Jeff King writes:
> From the user's perspective, I don't see how the implied relationships
> are significantly different. In type 1, they are placed inside a single
> value and in type 2, they are not. Both are a form of grouping.
>
> Moreover, I am not even sure that the syntax is an important e
On Sun, Feb 01, 2015 at 12:18:34PM -0800, Junio C Hamano wrote:
> I can see it argued that for things that are completely independent
> (e.g. the consequence of setting fsck.badDate can never be affected
> by how fsck.missingTagger is configured), separate configuration
> variables may not be wron
Michael Haggerty writes:
> On 01/28/2015 11:33 PM, Junio C Hamano wrote:
>> + When choosing the variable namespace, do not use variable name for
>> + specifying possibly unbounded set of things, most notably anything
>> + an end user can freely come up with (e.g. branch names), but also
>>
On Sun, Feb 01, 2015 at 06:12:38AM +0100, Michael Haggerty wrote:
> > + When choosing the variable namespace, do not use variable name for
> > + specifying possibly unbounded set of things, most notably anything
> > + an end user can freely come up with (e.g. branch names), but also
> > +
On 01/28/2015 11:33 PM, Junio C Hamano wrote:
> We may want to say something about command line option names in the
> new section as well, but for now, let's make sure everybody is clear
> on how to structure and name their configuration variables.
>
> The text for the rules are partly taken from
We may want to say something about command line option names in the
new section as well, but for now, let's make sure everybody is clear
on how to structure and name their configuration variables.
The text for the rules are partly taken from the log message of
Jonathan's 6b3020a2 (add: introduce a
10 matches
Mail list logo
