Messages in this thread | | | Date | Wed, 28 Sep 2022 07:54:09 +0200 | Subject | Re: [PATCH 5.19 014/207] Revert "usb: add quirks for Lenovo OneLink+ Dock" | From | Jiri Slaby <> |
| |
On 27. 09. 22, 8:31, Greg Kroah-Hartman wrote: > On Tue, Sep 27, 2022 at 08:18:26AM +0200, Jiri Slaby wrote: >> On 27. 09. 22, 7:47, Greg Kroah-Hartman wrote: >>> On Tue, Sep 27, 2022 at 07:23:46AM +0200, Jiri Slaby wrote: >>>> I wonder, does it make sense to queue the commit (as 011/207) and >>>> immediately its revert (the patch below) in a single release? I doubt >>>> that... >>>> >>>> The same holds for 012 (patch) + 015 (revert). >>> >>> Yes it does, otherwise tools will pick up "hey, you forgot this patch >>> that should have been applied here!" all the time. Having the patch, >>> and the revert, in the tree prevents that from happening. >> >> It'd be fairly easy to fix the tools not to pick up reverted commits, right? > > Not really as they are usually quite "far" away from the original > commits.
Yes, but you need to deal with this only in a particular release (a revert has to be applied if the commit is already in some previous release, of course).
> But hey, if you have some scripts that can find all of that, I'm all for > it, the ones I have right now don't account for this.
I don't know your/Sasha's scripts. But they are apparently able to find the revert as can we see above. So instead of direct: cherry-pick revert-patch-for-commit-X it would be: if (PATCH=`git grep -l "[Cc]ommit X" queue-RELEASE/`) git rm PATCH else cherry-pick revert-patch-for-commit-X fi
Or am I missing something?
thanks, -- js
| |