Re: [GIT PULL] bluetooth 2026-09-07

On Tue, Sep 15, 2026 at 03:36:50PM -0400, Luiz Augusto von Dentz wrote:

On Tue, Sep 15, 2026 at 3:24 PM Mark Brown [off-list ref] wrote:

quoted

On Tue, Sep 15, 2026 at 03:16:21PM -0400, Luiz Augusto von Dentz wrote:

quoted

Yes, the routine cherry picking is certainly part of it - it's not so
much the fact that things get moved between branches as the fact that
when you have the same commit is in multiple branches and then build on
top of one or both of them this creates extra conflicts, often harder to
understand, when the branches are merged.  The more normal thing would
be to apply once to the right place, or the standard fallback from that
would be to drop the commit from branch A at the time it is moved to
branch B.

If I merge to bluetooth, then bluetooth-next won't contain the fixes
meant for stable/rc, so I will need to merge them back to
bluetooth-next immediately it order for our CI to stay current with
the fixes.

Or have your CI merge the branches and run on that (that's a fairly
widely deployed approach).

quoted

You do seem to end up removing the cherry picked commits from their
original branches at some point as part of your workflow (since there
are hardly any duplicate bluetooth commits in mainline) so they do wind
up being moves AFAICT but the duplicates get left sitting there for
quite a while.

Yep, once before sending the pull request for net-next, bluetooth-next
is rebased on top of net-next which brings all the fixes already
merged back to bluetooth-next. Git is absolutely fine with that, I
don't think I ever run into a conflict doing this. Git detects the
fixes already present in net-next as duplicates and eliminates them,
so it really surprises me when you say you are finding conflicts, not
just duplicates.

The issue is not your rebase working, the issue is that until you get
round to doing that rebase anyone that merges both bluetooth and the net
trees (ot Linus' tree for that matter, often the conflicts are with his
tree) sees the duplicated commits and that routinely generates
conflicts.  This obviously comes up an awful lot with -next, I am not
rebasing the trees but rather merging them, but do I gather from some
conversations that other people are seeing this as part of their
workflows.

Anyway, to return to my prior question: should you be a contact for the
bluetooth tree?