Messages in this thread | | | Date | Wed, 25 May 2022 14:34:29 +0200 | Subject | Re: [GIT PULL] platform-drivers-x86 for 5.19-1 | From | Hans de Goede <> |
| |
Hi,
On 5/24/22 19:17, Linus Torvalds wrote: > On Mon, May 23, 2022 at 11:47 PM Hans de Goede <hdegoede@redhat.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
| |