On Tue, Oct 23, 2018 at 5:04 PM Al Viro <viro@xxxxxxxxxxxxxxxxxx> 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
