linux-kernel - Re: [PATCH RESEND v4] MAINTAINERS: fix lots of alphabetic ordering

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CA+55aFwZM+7uGLmw2fDnw+4tUeZpUK4ZTaM6paT7WUGDEYQVNw@mail.gmail.com>
Date:   Wed, 19 Jul 2017 21:53:42 -0700
From:   Linus Torvalds <torvalds@...ux-foundation.org>
To:     "Theodore Ts'o" <tytso@....edu>,
        Linus Torvalds <torvalds@...ux-foundation.org>,
        Joe Perches <joe@...ches.com>,
        Andrew Morton <akpm@...ux-foundation.org>,
        Randy Dunlap <rdunlap@...radead.org>,
        LKML <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH RESEND v4] MAINTAINERS: fix lots of alphabetic ordering

On Wed, Jul 19, 2017 at 9:36 PM, Theodore Ts'o <tytso@....edu> wrote:
>>
>> Maybe we can just do the prefix thing and just do 26 files A-Z
>> instead? Or maybe go by first word (so all the ARM things would go in
>> one place?)
>
> Is that really going to help with merge conflicts?  It might help keep
> things more in order, but if there is a merge conflict caused by two
> changes to adjacent entries causing patch "fuzz", splitting things
> into 26 files A-Z isn't going to significantly decrease the odds of
> this happening.

So it would actually help me a lot with conflicts - not because they'd
happen less, but because *when* they happen, the end result is much
easier to look at.

When I resolve a conflict, I always want to look at the commits that
cause the conflict. So what do I do? I do

    gitk HEAD...MERGE_HEAD <conflicting file>

and then with the MAINTAINERS file, I literally see *all* those
hundreds of changes.

You can just do

    gitk v4.12.. MAINTAINERS

with the current tree to get a feel for it.  It's just nasty. Now
imagine that you have to find the two commits that clash among the
100+ commits that have absolutely nothing to do with those two.

If we split the MAINTAINER file up, I might still get the exact same
number of conflicts, but when I look at the history of the individual
files, it will be much saner. That's particularly true if we split up
by "first word" (eg "ADAPTEC" or "ARM" or "SECURITY" or whatever),
when instead of having tens of different development threads that all
end up touching one single MAINTAINERS file (with most of it being
entirely irrelevant to one particular conflict), you presumably have
just a very small handful (and those are now likely much more relevant
to the conflict at hand).

Basically, handling four (or whatever) conflicts per merge window is
nothing. But they are particularly _annoying_ conflicts.

(They are never actually _hard_ conflicts, or very meaningful either.
They are just annoying and frustrating exactly because they are so
pointlessly much harder to find than they really should need to be).

                         Linus