On Thu, 20 Jun 2024 at 16:44, Luiz Augusto von Dentz <luiz.dentz@xxxxxxxxx> wrote: > > Hi Krzysztof, > > On Thu, Jun 20, 2024 at 10:35 AM Krzysztof Kozlowski <krzk@xxxxxxxxxx> wrote: > > > > On 20/06/2024 16:30, patchwork-bot+bluetooth@xxxxxxxxxx wrote: > > > Hello: > > > > > > This pull request was applied to bluetooth/bluetooth-next.git (master) > > > by Luiz Augusto von Dentz <luiz.von.dentz@xxxxxxxxx>: > > > > > > On Wed, 12 Jun 2024 09:58:29 +0200 you wrote: > > >> From: Bartosz Golaszewski <bartosz.golaszewski@xxxxxxxxxx> > > >> > > >> Hi Marcel, Luiz, > > >> > > >> Please pull the following power sequencing changes into the Bluetooth tree > > >> before applying the hci_qca patches I sent separately. > > >> > > >> [...] > > > > > > Here is the summary with links: > > > - [GIT,PULL] Immutable tag between the Bluetooth and pwrseq branches for v6.11-rc1 > > > https://git.kernel.org/bluetooth/bluetooth-next/c/4c318a2187f8 > > > > > > Luiz, > > > > This pulls looks wrong. Are you sure you have correct base? The diffstat > > suggests you are merging into rc2, not rc3. This will be confusing in > > merge commit. It is much safer, including possible feedback from Linus, > > if you use exactly the same base. > > So you are saying I need to rebase? I usually only rebase when it > comes the time to do a pull-request using net-next as a base since > that is where bluetooth-next normally lands. > Technically you're all set - you pulled rc3 together with my tag. But if you pulled rc3 separately and then my tag, the merge commit for the latter would look much cleaner. And for the record: you don't need to rebase anything. Does net-next require you to? That would be weird. I assume they also are based on one of the RC tags. You almost never should rebase on top of an rc, instead you merge it into your branch and send the PR starting from the latest rc tag. Git is smart and will figure it out. You may be afraid you'll "lose" some commits because you will not see it in the immediate git log. That's true, they will be buried underneath the pile of Merge commits from upstream, but worry not: git will always find all commits missing from upstream when you do `git request-pull`. Bart > > Best regards, > > Krzysztof > > > > > -- > Luiz Augusto von Dentz
