On Thu, Jul 16, 2020 at 1:43 AM Jarod Wilson <ja...@redhat.com> wrote: > > On Wed, Jul 15, 2020 at 11:18 PM Andrew Lunn <and...@lunn.ch> wrote: ... > > I really think that before we consider changes like this, somebody > > needs to work on git tooling, so that it knows when mass renames have > > happened, and can do the same sort of renames when cherry-picking > > across the flag day. Without that, people trying to maintain stable > > kernels are going to be very unhappy. > > I'm not familiar enough with git's internals to have a clue where to > begin for something like that, but I suspect you're right. Doing > blanket renames in stable branches sounds like a terrible idea, even > if it would circumvent the cherry-pick issues. I guess now is as good > a time as any to start poking around at git's internals...
I haven't forgotten about this, just been tied up with other work. I spent a bit of time getting lost in git's internals, and the best idea I've had suggested to me is some sort of cherry-pick hook that executes an external script to massage variables back to old names for -stable backporting. Could live somewhere in-tree, and maintainers would have to know about it, but it would be reasonably painless. Ideally, I was thinking a semantic patch to filter the backported patch through, but haven't yet spent enough time playing with coccinelle to know if that's actually a viable idea, since it's designed to run on C code, not a patch, as I understand it. Worst-case, it'd be a shell script doing some awk/sed/whatever. -- Jarod Wilson ja...@redhat.com
