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
