[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <CAKfmpSfS43zxcAC-f16QJ3MmcQ8SC_h6CJBLsKFF3_c36uaY_g@mail.gmail.com>
Date: Wed, 12 Aug 2020 23:42:44 -0400
From: Jarod Wilson <jarod@...hat.com>
To: Andrew Lunn <andrew@...n.ch>
Cc: Netdev <netdev@...r.kernel.org>
Subject: Re: [RFC] bonding driver terminology change proposal
On Thu, Jul 16, 2020 at 1:43 AM Jarod Wilson <jarod@...hat.com> wrote:
>
> On Wed, Jul 15, 2020 at 11:18 PM Andrew Lunn <andrew@...n.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
jarod@...hat.com
Powered by blists - more mailing lists