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. -Peff
