vfs.git#fixes: how to deal with duplicates of cherry-picked commits?

vfs.git#fixes: how to deal with duplicates of cherry-picked commits?

[Al Viro]

	I'd just noticed that one of the commits in #fixes
(cachefiles: fix the race between cachefiles_bury_object() and rmdir(2))
got cherry-picked into mainline (with added S-o-b by Dave Howells);
my fault for not spotting that earlier.  Which way do you prefer to
handle that kind of thing?  Pull as-is (it merges clean, just results
in two copies of commit in the tree), rebase the other two commits
(e.g. on top of 4.19), send them as individual patches or perhaps
cherry-pick them into mainline on your own?  Up to you; pull request
for the branch would've been as below, with all commits independent
from each other.  The first one is the duplicate in question...

The following changes since commit ffc4c92227db5699493e43eb140b4cb5904c30ff:

  sysfs: Do not return POSIX ACL xattrs via listxattr (2018-09-18 07:30:48 -0400)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs.git fixes

for you to fetch changes up to 3df629d873f8683af6f0d34dfc743f637966d483:

  gfs2_meta: ->mount() can get NULL dev_name (2018-10-13 00:19:13 -0400)

----------------------------------------------------------------
Al Viro (3):
      cachefiles: fix the race between cachefiles_bury_object() and rmdir(2)
      ecryptfs_rename(): verify that lower dentries are still OK after lock_rename()
      gfs2_meta: ->mount() can get NULL dev_name

 fs/cachefiles/namei.c |  2 +-
 fs/ecryptfs/inode.c   | 11 ++++++++---
 fs/gfs2/ops_fstype.c  |  3 +++
 3 files changed, 12 insertions(+), 4 deletions(-)

Re: vfs.git#fixes: how to deal with duplicates of cherry-picked commits?

[Linus Torvalds]

On Tue, Oct 23, 2018 at 5:04 PM Al Viro <viro@zeniv.linux.org.uk> wrote:
>
>         I'd just noticed that one of the commits in #fixes
> (cachefiles: fix the race between cachefiles_bury_object() and rmdir(2))
> got cherry-picked into mainline (with added S-o-b by Dave Howells);
> my fault for not spotting that earlier.  Which way do you prefer to
> handle that kind of thing?  Pull as-is (it merges clean, just results
> in two copies of commit in the tree), rebase the other two commits
> (e.g. on top of 4.19), send them as individual patches or perhaps
> cherry-pick them into mainline on your own?

Just pull as-is.

Duplicate commits aren't a problem as ling as they aren't a pattern.
The occasional "oops" thing that doesn't cause any other issues isn't
worth worrying about.

In fact, duplicate commits are fairly normal for the "bugfix was
backported from the development branch" case. It gets annoying if they
cause nasty merge issues (due to other changes around the same area),
but even then it's usually not a big deal.

If it's a "oops I did it again" case that just keeps happening so much
that you write a catchy tune about it, _then_ it becomes a problem.

               Liinus

Re: vfs.git#fixes: how to deal with duplicates of cherry-picked commits?

[Linus Torvalds]

On Tue, Oct 23, 2018 at 5:04 PM Al Viro <viro@zeniv.linux.org.uk> wrote:
>
>   git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs.git fixes

Pulled.

Although I'd have appreciated more of a note about what was there,
outside of just the notice about the cherry-pick.

              Linus