On Wed, Jul 12 2017, Junio C. Hamano jotted: > Stefan Beller <sbeller@xxxxxxxxxx> 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 very much like Stefan's approach here[1]. It's very useful to be able to set something like this in a config on a project-wide basis, so that wherever patches are reviewed (in Gitweb, Git[hub|lab], git-format-patch etc.) they look as the project prefers. As Stefan points out we're already accomplishing this with Documentation as a result of a hack. But I see why you'd be concerned about this. If you're looking at random git repos there's a limit to what we'd like to allow them to customize without causing confusion. The diff order is relatively innocent, but you might make the case that other diff settings should be adjusted too (e.g. -U0 on certain file types), and that's quite the rabbit hole. Still, I think this is innocuous enough to stright the right balance between intrusion and usability. Some would find this *very* useful, think projects that for whatever reason need to commit e.g. verbose XML config along with their code, and the framework they're using happens to rely on conf/ and src/ directories. 1. Although nit: let's call it .gitorder not .gitorderfile, that it's a file is implicit. We don't have .gitignorefile, .gitattributesfile etc.
