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:20, Luiz Augusto von Dentz wrote:
> Hi,
> 
> On Thu, Jun 20, 2024 at 10:16 AM Luiz Augusto von Dentz
> <luiz.dentz@gmail.com> 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?
> 
> Looks like I just needed -no-ff, will be pushing it after it finishes compiling.

Ah, so there was a tag. You miss proper config option... Well, I am
surprised you do not have default pull.rebase set. How did you manage to
pull anything from anyone? Git requires it since some time.

Best regards,
Krzysztof