[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <YzKYyDaTsoX1RliA@kroah.com>
Date: Tue, 27 Sep 2022 08:31:36 +0200
From: Greg Kroah-Hartman <gregkh@...uxfoundation.org>
To: Jiri Slaby <jirislaby@...nel.org>
Cc: linux-kernel@...r.kernel.org, stable@...r.kernel.org,
Oliver Neukum <oneukum@...e.com>,
Jean-Francois Le Fillatre <jflf_kernel@....com>,
stable <stable@...nel.org>, Sasha Levin <sashal@...nel.org>
Subject: Re: [PATCH 5.19 014/207] Revert "usb: add quirks for Lenovo OneLink+
Dock"
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.
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.
thanks,
greg k-h
Powered by blists - more mailing lists