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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ