On Thu, Nov 15, 2018 at 2:44 PM Andreas Gruenbacher <agrue...@redhat.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