linux-kernel - Re: linux-next: build failure after merge of the drm tree

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: <CAKMK7uEQ8HPZ3PkAiEEoDoWXQL27GzoNNsNeyNqYrhu_3TDUPQ@mail.gmail.com>
Date:   Mon, 20 Mar 2017 09:03:48 +0100
From:   Daniel Vetter <daniel.vetter@...ll.ch>
To:     Stephen Rothwell <sfr@...b.auug.org.au>
Cc:     Dave Airlie <airlied@...ux.ie>,
        Intel Graphics <intel-gfx@...ts.freedesktop.org>,
        DRI <dri-devel@...ts.freedesktop.org>,
        linux-next <linux-next@...r.kernel.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        Chris Wilson <chris@...is-wilson.co.uk>,
        Jani Nikula <jani.nikula@...el.com>
Subject: Re: linux-next: build failure after merge of the drm tree

On Mon, Mar 20, 2017 at 1:51 AM, Stephen Rothwell <sfr@...b.auug.org.au> wrote:
> This cherry picking of fixes from new development back to Linus' tree
> can be a real pain when so many other changes happen in the same files.

One possible fix for this would be if you reuse our rerere cache. The
only reason we don't go insane with all the drm conflicts is that we
completely distributed conflict resolution. Developers push a patch,
script tells them there's a conflict, they resolve it, maintainers
never even notice.We only notice when we double-check the merge
resolution when rerere re-applies it for the real backmerge :-) The
merge order in drm-tip should also match what you have in linux-next,
so you should be able to entirely reuse them.

Anyway, if you trust us enough to scoop up random git rerere caches
(or at least use them to double-check your own), they're all public:

git://anongit.freedesktop.org/drm-tip rerere-cache

Or

https://cgit.freedesktop.org/drm-tip/tree/rr-cache?h=rerere-cache

Yes we should probably gc them, but disk space is cheap.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch