On Wed, May 8, 2019 at 3:37 PM Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx> wrote: > > On Wed, May 8, 2019 at 11:32 AM Steve French <smfrench@xxxxxxxxx> wrote: > > > > [..] Our > > build verification tests passed (and continue to be extended to > > include more tests). See e.g. our 'buildbot' results at: > > http://smb3-test-rhel-75.southcentralus.cloudapp.azure.com/#/builders/2/builds/199 > > Still, is there any reason for that very late rebase? > > Why are all the commits so recent? Most of the commits were from April, three from March, only a few more recent. I rebased yesterday (bad idea it seems based on your note) simply to avoid any potential merge conflict with the two broad VFS changes (unrelated to my PR) that hit cifs code yesterday (albeit they turned out to be very small). > And perhaps even more importantly, why is the base for that rebase is > some completely random and inappropriate commit in the middle of the > merge window? Understood. I had originally based it on v5.1 tag, but changed that for testing after I saw two other PR's hit I wanted to run the regression tests on 'current' mainline with the changes in for-next code just in case (very unlikely) the other two changes that I hadn't seen that hit cifs since 5.1 broke anything or caused conflicts. > So don't do the whole "rebase the day before" in the first place, but > *DEFINITELY* don't do it when you then pick a random and bad point to > rebase things on top of! Understood - will do the rebase for our verification testing only (e.g. to spot any regressions in recent global or VFS changes) but not for sending to you. So for future, will try to send with base as that of mainline kernel as of he last cifs PR merge or new kernel version or rc (e.g. v5.2-rc1 or v5.1 etc) whichever is more recent. Is that ok? -- Thanks, Steve
