On Thu, 2017-01-19 at 00:38 -0500, David Miller wrote: > From: Tom Herbert <t...@herbertland.com> > Date: Wed, 18 Jan 2017 21:22:53 -0800 > > > In principle I agree, but as I previously wrote backporting this > > driver is already a bear. We need to do something here as this is > > quickly approaching being infeasible to backport. Even if we don't > > restructure the directories I'd still like to see some effort > towards > > feature modularization and isolation. > > There simply is a lot changing all the time, no restructuring is > going > to reduce that. The driver simply gets a lot of churn. > > Backporting such things through a bunch of file and/or directory > renames is seriously nothing but asking for more punishment. > > That's why I am against it.
So, I spent the better part of two years dealing with this after the drivers/net/mellanox drivers/net/ethernet/mellanox rename, so I'll chime in. Especially since Tom's problem directly relates to the issues I dealt with when trying to take the latest Mellanox driver and shoe-horn it into a Red Hat kernel that didn't have the same net core (I had to pick and choose which mlx patches to take in order to work with our existing net core, and the files were renamed on top of that). If you rename a file from place A to place B and keep the file the same, then a git backport can be done using techniques such as git cherry-pick with the --follow option enabled. It's slow, but works. But that's not what you've brought up. You brought up continuing the rename to go further and split code out into files based upon features. While git cherry-pick can follow renames mostly automatically, it can not follow refactors. If they move the tcflower stuff out to a file on its own, and you then attempt to backport some fix that touches the tcflower support in the new location while you have not taken the move patch, you will find that git will be totally stymied. What you have now is not perfect and you have to sort through commits to get the right ones and skip the ones you can't support, but things mostly apply except when context diffs break issues. With the refactor and separation you speak of, git will be totally unable to help and you will have to manually edit patches to point at new files or hand edit the files to apply the patches. I understand the desire for order instead of chaos, but it really will not help. Bringing patches from the new order back to the old chaos will be so much harder than just continuing as things are that you will silently curse the change shortly after it is made. -- Doug Ledford <dledf...@redhat.com> GPG KeyID: B826A3330E572FDD Key fingerprint = AE6B 1BDA 122B 23B4 265B 1274 B826 A333 0E57 2FDD
signature.asc
Description: This is a digitally signed message part
