linux-kernel - Re: [GIT PULL] gfs2: 4.20 fixes

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] [day] [month] [year] [list]

Message-ID: <CAHk-=wgNS==_EbLtWQe5xWQ4Q1QP4UTwd4f33QVg4WLzR+y46Q@mail.gmail.com>
Date:   Fri, 16 Nov 2018 11:51:43 -0600
From:   Linus Torvalds <torvalds@...ux-foundation.org>
To:     agruenba@...hat.com
Cc:     cluster-devel@...hat.com,
        Linux List Kernel Mailing <linux-kernel@...r.kernel.org>
Subject: Re: [GIT PULL] gfs2: 4.20 fixes

On Thu, Nov 15, 2018 at 2:44 PM Andreas Gruenbacher <agruenba@...hat.com> wrote:
>
> Ok, I've changed the merge commit as follows now:
>
>     Merge tag 'v4.20-rc1'
>
>     Pull in the gfs2 fixes that went into v4.19-rc8:
>
>       gfs2: Fix iomap buffered write support for journaled files
>       gfs2: Fix iomap buffered write support for journaled files (2)
>
>     Without these two commits, the following fix would cause conflicts.
>
> So merging v4.19-rc8 would have been sufficient. v4.20-rc1 is what I
> ended up testing, though.
>
> Are you okay with that now?

If the only reason for this was the trivial one-liner conflict, the
real fix is to just not do the merge at all, and not worry about
conflicts.

I handle simple conflicts like this in my sleep. It's actually much
better and clearer if the development trees just do their own
development, and not worry about "Oh, Linus will get a small conflict
due to other changes he has pulled".

So what I did was to actually try to generate the tree I think it
*should* have been, and just merge that with the simple conflict
resolution.

You might want to double-check it - not only because I rewrote your
pull to not have the merge at all, and in the process modified things,
but just to see what I think the right approach would have been.

Now, there *are* reasons to do back-merges, but no, "Oh, there's a
trivial conflict" is not one of them.

                  Linus