[Intel-xe] [PATCH 0/7] drm/xe: Code cleanup

[Lucas De Marchi]

On Tue, Aug 08, 2023 at 06:05:40PM +0300, Jani Nikula wrote:
>On Tue, 08 Aug 2023, Lucas De Marchi <lucas.demarchi at intel.com> wrote:
>> On Tue, Aug 08, 2023 at 01:47:50PM +0300, Jani Nikula wrote:
>>>On Mon, 17 Jul 2023, Lucas De Marchi <lucas.demarchi at intel.com> wrote:
>>>> On Thu, Jul 13, 2023 at 04:33:52PM -0400, Rodrigo Vivi wrote:
>>>>>On Thu, Jul 13, 2023 at 03:06:04PM +0000, Francois Dugast wrote:
>>>>>> Fix minor typos and reduce ERRORs reported by checkpatch.pl from 95 to 22.
>>>>>
>>>>>I wonder if we should do this with !fixup patches...
>>>>
>>>> I think that would be a nightmare to thread through the conflicts.
>>>
>>>For display it's a nightmare we have to plunge through. And this just
>>>made it worse.
>>
>> This is automatically resolved when we move display up in the branch
>> though.  "Automatically" meaning that the pour sould doing the rebase
>> has to resolve the conflicts. I don't like doing it, but what's the
>> alternative? Last rebase I did a "squash-heavy approach" because moving
>> display up means some commits don't make sense anymore, even if they
>> apply correctly.  Those coding style changes would just be squashed in
>> the respective commits.
>
>Squashing is easy if you have respective commits with 1:1 mapping, but
>if you have one commit fixing multiple commits, it gets tricky.

no, what I meant is that I turned 10 or so commits into 1 squash to the
"Add display".  Simply because after moving them up in the branch they
don't make much sense anymore and just make it difficult to land
refactors like this on top. It's a nightmare to keep in the long run
that I should rather avoid. IMO it was fine for a few weeks, but not for
the several months we are in this situation.

Lucas De Marchi