Re: [GIT PULL] Immutable tag between the Bluetooth and pwrseq branches for v6.11-rc1

[Krzysztof Kozlowski <krzk@kernel.org>]

On 20/06/2024 16:16, Luiz Augusto von Dentz wrote:
> Hi Bartosz,
> 
> On Wed, Jun 19, 2024 at 3:40 PM Bartosz Golaszewski <brgl@bgdev.pl> wrote:
>>
>> On Wed, Jun 19, 2024 at 8:59 PM Luiz Augusto von Dentz
>> <luiz.dentz@gmail.com> wrote:
>>>
>>> Hi Bartosz,
>>>
>>> On Wed, Jun 19, 2024 at 3:35 AM Bartosz Golaszewski <brgl@bgdev.pl> wrote:
>>>>
>>>> On Wed, Jun 12, 2024 at 5:00 PM Bartosz Golaszewski <brgl@bgdev.pl> wrote:
>>>>>
>>>>> On Wed, Jun 12, 2024 at 4:54 PM Luiz Augusto von Dentz
>>>>> <luiz.dentz@gmail.com> wrote:
>>>>>>
>>>>>> Hi Bartosz,
>>>>>>
>>>>>> On Wed, Jun 12, 2024 at 10:45 AM Bartosz Golaszewski <brgl@bgdev.pl> wrote:
>>>>>>>
>>>>>>> On Wed, Jun 12, 2024 at 4:43 PM Luiz Augusto von Dentz
>>>>>>> <luiz.dentz@gmail.com> wrote:
>>>>>>>>
>>>>>>>> Hi Bartosz,
>>>>>>>>
>>>>>>>> On Wed, Jun 12, 2024 at 3:59 AM Bartosz Golaszewski <brgl@bgdev.pl> wrote:
>>>>>>>>>
>>>>>>>>> From: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
>>>>>>>>>
>>>>>>>>> Hi Marcel, Luiz,
>>>>>>>>>
>>>>>>>>> Please pull the following power sequencing changes into the Bluetooth tree
>>>>>>>>> before applying the hci_qca patches I sent separately.
>>>>>>>>>
>>>>>>>>> Link: https://lore.kernel.org/linux-kernel/20240605174713.GA767261@bhelgaas/T/
>>>>>>>>>
>>>>>>>>> The following changes since commit 83a7eefedc9b56fe7bfeff13b6c7356688ffa670:
>>>>>>>>>
>>>>>>>>>   Linux 6.10-rc3 (2024-06-09 14:19:43 -0700)
>>>>>>>>>
>>>>>>>>> are available in the Git repository at:
>>>>>>>>>
>>>>>>>>>   git://git.kernel.org/pub/scm/linux/kernel/git/brgl/linux.git tags/pwrseq-initial-for-v6.11
>>>>>>>>>
>>>>>>>>> for you to fetch changes up to 2f1630f437dff20d02e4b3f07e836f42869128dd:
>>>>>>>>>
>>>>>>>>>   power: pwrseq: add a driver for the PMU module on the QCom WCN chipsets (2024-06-12 09:20:13 +0200)
>>>>>>>>>
>>>>>>>>> ----------------------------------------------------------------
>>>>>>>>> Initial implementation of the power sequencing subsystem for linux v6.11
>>>>>>>>>
>>>>>>>>> ----------------------------------------------------------------
>>>>>>>>> Bartosz Golaszewski (2):
>>>>>>>>>       power: sequencing: implement the pwrseq core
>>>>>>>>>       power: pwrseq: add a driver for the PMU module on the QCom WCN chipsets
>>>>>>>>
>>>>>>>> Is this intended to go via bluetooth-next or it is just because it is
>>>>>>>> a dependency of another set? You could perhaps send another set
>>>>>>>> including these changes to avoid having CI failing to compile.
>>>>>>>>
>>>>>>>
>>>>>>> No, the pwrseq stuff is intended to go through its own pwrseq tree
>>>>>>> hence the PR. We cannot have these commits in next twice.
>>>>>>
>>>>>> Not following you here, why can't we have these commits on different
>>>>>> next trees? If that is the case how can we apply the bluetooth
>>>>>> specific ones without causing build regressions?
>>>>>>
>>>>>
>>>>> We can't have the same commits twice with different hashes in next
>>>>> because Stephen Rothwell will yell at us both.
>>>>>
>>>>> Just pull the tag I provided and then apply the Bluetooth specific
>>>>> changes I sent on top of it. When sending to Linus Torvalds/David
>>>>> Miller (not sure how your tree gets upstream) mention that you pulled
>>>>> in the pwrseq changes in your PR cover letter.
>>>
>>> By pull the tag you mean using merge commits to merge the trees and
>>> not rebase, doesn't that lock us down to only doing merge commits
>>> rather than rebases later on? I have never used merge commits before.
>>> There is some documentation around it that suggests not to use merges:
>>>
>>> 'While merges from downstream are common and unremarkable, merges from
>>> other trees tend to be a red flag when it comes time to push a branch
>>> upstream. Such merges need to be carefully thought about and well
>>> justified, or there’s a good chance that a subsequent pull request
>>> will be rejected.'
>>> https://docs.kernel.org/maintainer/rebasing-and-merging.html#merging-from-sibling-or-upstream-trees
>>>
>>> But then looking forward in that documentation it says:
>>>
>>> 'Another reason for doing merges of upstream or another subsystem tree
>>> is to resolve dependencies. These dependency issues do happen at
>>> times, and sometimes a cross-merge with another tree is the best way
>>> to resolve them; as always, in such situations, the merge commit
>>> should explain why the merge has been done. Take a moment to do it
>>> right; people will read those changelogs.'
>>>
>>> So I guess that is the reason we want to merge the trees, but what I'm
>>> really looking forward to is for the 'proper' commands and commit
>>> message to use to make sure we don't have problems in the future.
>>>
>>
>> You shouldn't really need to rebase your branch very often anyway.
>> This is really for special cases. But even then you can always use:
>> `git rebase --rebase-merges` to keep the merge commits.
>>
>> The commands you want to run are:
>>
>> git pull git://git.kernel.org/pub/scm/linux/kernel/git/brgl/linux.git
>> tags/pwrseq-initial-for-v6.11
>> git am or b4 shazam on the patches targeting the Bluetooth subsystem
>> git push
> 
> Not quite working for me:
> 
> From git://git.kernel.org/pub/scm/linux/kernel/git/brgl/linux
>  * tag                         pwrseq-initial-for-v6.11 -> FETCH_HEAD
> hint: You have divergent branches and need to specify how to reconcile them.
> hint: You can do so by running one of the following commands sometime before
> hint: your next pull:
> hint:
> hint:   git config pull.rebase false  # merge
> hint:   git config pull.rebase true   # rebase
> hint:   git config pull.ff only       # fast-forward only
> hint:
> hint: You can replace "git config" with "git config --global" to set a default
> hint: preference for all repositories. You can also pass --rebase, --no-rebase,
> hint: or --ff-only on the command line to override the configured default per
> hint: invocation.
> fatal: Need to specify how to reconcile divergent branches.
> 
> Perhaps I need to configure pull.rebase to be false?

tag goes as last argument. (git help pull)

Best regards,
Krzysztof