Date:   Wed, 25 May 2022 14:34:29 +0200
From:   Hans de Goede <hdegoede@...hat.com>
To:     Linus Torvalds <torvalds@...ux-foundation.org>
Cc:     Andy Shevchenko <andy@...radead.org>,
        Mark Gross <mark.gross@...el.com>,
        LKML <linux-kernel@...r.kernel.org>,
        Thomas Gleixner <tglx@...utronix.de>,
        "Peter Zijlstra (Intel)" <peterz@...radead.org>
Subject: Re: [GIT PULL] platform-drivers-x86 for 5.19-1

Hi,

On 5/24/22 19:17, Linus Torvalds wrote:
> On Mon, May 23, 2022 at 11:47 PM Hans de Goede <hdegoede@...hat.com> wrote:
>>
>> I did do a "git remote update origin" recently (recent-ish), but
>> AFAIK that does not help.
> 
> Hmm. Did you pass in 'origin' to git request-pull too?
> 
>> I did read somewhere that in cases like this some maintainers
>> create a branch with a merge of their for-next branch [..]
> 
> No, that's only necessary for when the branch has merges and can have
> multiple merge bases as a result - that will make 'git diff' unable to
> find an unambiguous place to start the diff from (see
> Documentation/maintainer/messy-diffstat.rst for the details).
> 
> But your tree doesn't have that issue, and you can also see the old
> commits in your shortlog (and the "messy diffstat" is _only_ about the
> diff, not about the commit list). And you can see the same effect in
> the shortlog, ie I merged your earlier fixes pull request  in commit
> 9be9ed2612b5 ("Merge tag 'platform-drivers-x86-v5.18-4' of
> git://..."), and it already had
> 
>     * tag 'platform-drivers-x86-v5.18-4' of
> git://git.kernel.org/pub/scm/linux/kernel/git/pdx86/pla>
>       platform/surface: aggregator: Fix initialization order when
> compiling as builtin module
>       platform/surface: gpe: Add support for Surface Pro 8
>       platform/x86/intel: Fix 'rmmod pmt_telemetry' panic
>       platform/x86: thinkpad_acpi: Correct dual fan probe
>       platform/x86: thinkpad_acpi: Add a s2idle resume quirk for a
> number of laptops
>       platform/x86: thinkpad_acpi: Convert btusb DMI list to quirks
> 
> but notice how your pll request had those commits listed again (ie it
> had, for example:
> 
>   Maximilian Luz (2):
>         platform/surface: gpe: Add support for Surface Pro 8
>         platform/surface: aggregator: Fix initialization order when
> compiling as builtin module
> 
> in there).

Right, that is a result of my standard workflow which goes like this:

1. After v5.18-rc1 fast-forward both my for-next and fixes branches
to v5.18-rc1

2. Merge new patches into for-next

3. If there are fixes cherry-pick them from for-next into my fixes
branch

4. Send a couple of fixes pull-req from the fixes branch to you
during the cycle

5. run:

git tag -s platform-drivers-x86-v5.19-1 for-next
git request-pull v5.18-rc1 git://git.kernel.org/pub/scm/linux/kernel/git/pdx86/platform-drivers-x86.git platform-drivers-x86-v5.19-1 > pull

Open pull file in editor and use it in my pull-req email.


Which AFAIK is a pretty standard workflow; and AFAIK there is
no way to avoid the double listing of fixes already merged
in both the shortlog and the diffstat in the pullreq.

I welcome any suggestions to improve the above workflow.

> And while merges can confuse the diffstat, the actual commit list
> doesn't care: it does a proper set operation, and having multiple
> merge bases doesn't matter.
> 
> This all is not a huge deal - I figured out what was going on, so it
> wasn't a problem.
> 
> I just mentioned it because that whole "Linus figures it out" does
> take some time and effort, and I'm really really lazy and much prefer
> to just do the pull and look at the result and go "Yeah, looks good"
> and go on to the next one...

I understand and if there is a way to make your life easier I'm
all for it.

Regards,

Hans

Powered by blists - more mailing lists