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]
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

Powered by blists - more mailing lists