On Thu, 12 Dec 2024, Raag Jadav <raag.jadav@xxxxxxxxx> wrote: > On Thu, Dec 12, 2024 at 09:36:00AM +0100, Andi Shyti wrote: >> Hi Raag, >> >> On Thu, Dec 12, 2024 at 05:22:32AM +0200, Raag Jadav wrote: >> > On Thu, Dec 12, 2024 at 12:40:07AM +0100, Andi Shyti wrote: >> > > > Raag Jadav (4): >> > > > drm/intel/pciids: Refactor DG2 PCI IDs into segment ranges >> > > > drm/i915/dg2: Introduce DG2_D subplatform >> > > > drm/i915: Introduce intel_cpu_info.c for CPU IDs >> > > > drm/i915/dg2: Implement Wa_14022698537 >> > > >> > > merged to drm-intel-next. >> > >> > Thanks, appreciate it. >> > >> > Andy usually picks the cover letter as well, we don't do that here? >> >> what do you mean with taking the cover letter? >> >> For pushing the patch I use the dim tool and I feed it with the >> cover letter's mbox file. > > Ah okay. I think he uses b4 with cover letter as a merge patch. Kind of > like treating it as a PR. It's useful when we have a nice summary which > adds required context (which I understand is not the case here anyway). > > Examples, > > $ git show 563532b49aa0aa00 > $ git show e4e17186723570e8 I assume this was done using 'b4 shazam --merge'. With 10+k commits merged each release, we'd get an insane amount of placeholder "Merge patch series" merge commits, without an actual merge of branches, if we chose this approach. IMO each patch and thus commit should stand on its own merits, and contain all the information required, without depending on the cover letter having been merged for informational purposes. Also, there doesn't appear to be a single merge like that under drm. BR, Jani. -- Jani Nikula, Intel
