On Fri, 22 Jul 2022 17:25:57 -0700 Luiz Augusto von Dentz wrote: > > > Crap, let me fix them. > > > > Do you mean i should hold off with pushing or you'll follow up? > > Ive just fixup the original patch that introduced it, btw how do you > run sparse to capture such errors? We run builds with W=1 C=1 in the CI and then diff the outputs. That's pretty noisy so we have a regex which counts number of warnings per file, that makes it possible to locate the exact new warning. At least most of the time... > > > Yep, that happens when I rebase on top of net-next so I would have to > > > redo all the Signed-off-by lines if the patches were originally > > > applied by Marcel, at least I don't know of any option to keep the > > > original committer while rebasing? > > > > I think the most common way is to avoid rebasing. Do you rebase to get > > rid of revised patches or such? > > So we don't need to rebase? No, not usually. After we pull from you, you should pull back from us (git pull --ff-only $net-or-net-next depending on the tree you targeted), and that's it. The only patches that go into your tree then are bluetooth patches, everything else is fed via pulling back from us. > There were some patches already applied via bluetooth.git so at least > I do it to remove them Normally you'd not apply bluetooth fixes to bluetooth-next, apply them to bluetooth and send us a PR. Then once a week we'll merge net (containing your fixes) into net-next, at which point you can send a bluetooth-next PR and get the fixes into bluetooth-next. FWIW from our perspective there's no limit on how often you send PRs. Alternatively you could apply the fixes into bluetooth and then merge bluetooth into bluetooth-next. If you never rebase either tree, git will be able to figure out that it's the same commit hash even if it makes it to the tree twice (once thru direct merge and once via net). That said, I believe Linus does not like cross tree merges, i.e. merges which are not fast forwards to the downstream tree. So it's better to take the long road via bt -> net -> net-next -> bt-next. > and any possible conflicts if there were > changes introduced to the bluetooth directories that can eventually > come from some other tree. Conflicts are not a worry, just let us know in the PR description how to resolve them.
