On Wed, Jul 15, 2020 at 11:18 PM Andrew Lunn <and...@lunn.ch> wrote: > > On Wed, Jul 15, 2020 at 11:04:16PM -0400, Jarod Wilson wrote: > > On Mon, Jul 13, 2020 at 8:26 PM Andrew Lunn <and...@lunn.ch> wrote: > > > > > > Hi Jarod > > > > > > Do you have this change scripted? Could you apply the script to v5.4 > > > and then cherry-pick the 8 bonding fixes that exist in v5.4.51. How > > > many result in conflicts? > > > > > > Could you do the same with v4.19...v4.19.132, which has 20 fixes. > > > > > > This will give us an idea of the maintenance overhead such a change is > > > going to cause, and how good git is at figuring out this sort of > > > thing. > > > > Okay, I have some fugly bash scripts that use sed to do the majority > > of the work here, save some manual bits done to add duplicate > > interfaces w/new names and some aliases, and everything is compiling > > and functions in a basic smoke test here. > > > > Summary on the 5.4 git cherry-pick conflict resolution after applying > > changes: not that good. 7 of the 8 bonding fixes in the 5.4 stable > > branch required fixing when straight cherry-picking. Dumping the > > patches, running a sed script over them, and then git am'ing them > > works pretty well though. > > Hi Jarad > > That is what i was expecting. > > 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... -- Jarod Wilson ja...@redhat.com
