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

From: Jeff King <peff@peff.net>
Date: Jul 13, 2017, 16:00 UTC
Message-ID: <20170713160014.laowcywx7pb5we77@sigill.intra.peff.net>
In-Reply-To: <xmqqa849yzwh.fsf@gitster.mtv.corp.google.com>

On Wed, Jul 12, 2017 at 04:54:38PM -0700, Junio C Hamano wrote:

Show 23 quoted lines

> Jeff King <peff@peff.net> 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.

-Peff