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 PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Fri, 12 Jun 2020 22:32:15 -0700 From: "Darrick J. Wong" <darrick.wong@...cle.com> To: Linus Torvalds <torvalds@...ux-foundation.org> Cc: "Darrick J. Wong" <djwong@...nel.org>, linux-fsdevel <linux-fsdevel@...r.kernel.org>, linux-xfs <linux-xfs@...r.kernel.org>, Dave Chinner <david@...morbit.com>, Linux Kernel Mailing List <linux-kernel@...r.kernel.org>, Eric Sandeen <sandeen@...deen.net>, Christoph Hellwig <hch@....de>, linux-ext4 <linux-ext4@...r.kernel.org>, "Theodore Ts'o" <tytso@....edu>, ira.weiny@...el.com Subject: Re: [GIT PULL] vfs: improve DAX behavior for 5.8, part 3 On Thu, Jun 11, 2020 at 11:00:43AM -0700, Linus Torvalds wrote: > On Wed, Jun 10, 2020 at 7:43 PM Darrick J. Wong <djwong@...nel.org> wrote: > > > > I did a test merge of this branch against upstream this evening and > > there weren't any conflicts. The first five patches in the series were > > already in the xfs merge, so it's only the last one that should change > > anything. Please let us know if you have any complaints about pulling > > this, since I can rework the branch. > > I've taken this, but I hate how the patches apparently got duplicated. > It feels like they should have been a cleanly separated branch that > was just pulled into whoever needed them when they were ready, rather > than applied in two different places. > > So this is just a note for future work - duplicating the patches like > this can cause annoyances down the line. No merge issues this time > (they often happen when duplicate patches then have other work done on > top of them), but things like "git bisect" now don't have quite as > black-and-white a situation etc etc., > > ("git bisect" will still find _one_ of the duplicate commits if it > introduced a problem, so it's usually not a huge deal, but it can > cause the bug to be then repeated if people revert that one, but > nobody ever notices that the other commit that did the same thing is > still around and it gets back-ported to stable or whatever..) > > So part of this is just in general about confusing duplicate history, > and part of it is that the duplication can then cause later confusion. Urgh, sorry. I /was/ careful to make sure the patches matched, but I'll be more careful the next time this (hopefully never) happens again. :/ --D > Linus
Powered by blists - more mailing lists