Re: [PATCH] RFC: Introduce '.gitorderfile'
- Date: Thu, 13 Jul 2017 12:00:14 -0400
- From: Jeff King <peff@xxxxxxxx>
- Subject: Re: [PATCH] RFC: Introduce '.gitorderfile'
On Wed, Jul 12, 2017 at 04:54:38PM -0700, Junio C Hamano wrote:
> Jeff King <peff@xxxxxxxx> writes:
> > 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.
> Yeah, and that opens a whole can of worms.
> We let projects to ship clean/smudge or textconv filters and also
> mark paths to which these tools may be of help, but we do not let
> projects to automatically enable them in the cloned repository. The
> projects must _tell_ the user how to run the last step (e.g. "There
> is a tools/setup-my-clone script shipped with the source; running it
> will add necessary configurations to work better with our project").
> I do not think usefulness of diff.orderfile is being questioned, but
> I think it is something we should treat just like any other thing
> that affects repository configuration. A .gitorderfile that allows
> the project to behave as if we allowed to auto-enable just one thing
> in the clone, while not allowing others, a source of issues and
> unnecessary headaches later.
Thanks for writing this out. That was exactly what I was trying to imply
with my final statement, but you said it much better. :)
> Besides, diff-order is *not* the only order that matters in the use
> of the system, and we _will_ regret the name ".gitorderfile" later,
> as people would start making noises about forcing ls-files and other
> things to also show the list following that order.
I'd also agree with this.