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,