Re: [PATCH] RFC: Introduce '.gitorderfile'

From: Stefan Beller <sbeller@google.com>
Date: Jul 12, 2017, 21:08 UTC
Message-ID: <CAGZ79kYYg6-UMrKRPeJTbHdGR0juZ2OwFZmkuYgeYe5X+cm_sQ@mail.gmail.com>
In-Reply-To: <20170712205734.h77fgbbkavwpkr4h@sigill.intra.peff.net>

On Wed, Jul 12, 2017 at 1:57 PM, Jeff King <peff@peff.net> wrote:

Show 25 quoted lines

> On Wed, Jul 12, 2017 at 01:44:46PM -0700, Junio C Hamano wrote:
>
>> Stefan Beller <sbeller@google.com> writes:
>>
>> >   I want to force myself to think about the design before pointing out
>> >   memory leaks and coding style, so the least I would wish for is:
>> >     *.h
>> >     *.c
>> >   but as we have more to look at, I would want to have the most abstract
>> >   thing to come first. And most abstract from the actual code is the
>> >   user interaction, the documentation.
>>
>> This is exactly why I invented the orderfile in the first place.
>> But such a "policy" is not something a project would want to enforce
>> its users all the time; it is left to personal preference of the
>> participants.
>>
>> Just set diff.orderFile to suit your taste without bothering other
>> people, I would say.
>
> I could see somebody arguing that format-patch should respect a project
> preference, since its primary purpose is to communicate your work to the
> rest of the project.
>
> But then you could make a similar argument for other diff options, too.

This similar argument would be to have a in-tree configuration for --unified=<N> for example?

This triggers two reactions for me:

(a) We should totally do that.
  Different projects have different coding styles (e.g. opening brace
  in its own new line or at the end of the condition), which very much impacts
  how useful the context is. So, sure, the project knows best what their
  preference is.

(b) It's a rabbit hole to go down.
  Any config option that format-patch respects can be argued to be useful
  to be preset by a project. So in the end we'd have a ".gitconfig"
file offering
  good defaults for people using that project. This may have security
implications.
  And it's a lot of work.

I see your point for (b), I'll think about it more.

Thanks, Stefan