Hi Bart,
On Thu, 3 Mar 2022, Bart Van Assche wrote:
> On 3/3/22 15:38, Joe Perches wrote:
> > One argument is that churn leads to difficulty in backporting fixes to
> > older 'stable' versions.
> >
> > I think the churn argument is overstated.
>
> I'm often backporting patches to older kernels and I think the churn
> argument has not been emphasized enough. Backporting patches is a normal
> aspect of a product lifecycle since a kernel version is chosen when
> development of a product starts and bugfixes are cherry-picked from
> upstream selectively.
>
That should not be an issue. One of the benefits of having a canonical
form for source code is that you also get a canonical form for patches.
Let's say you receive a patch (or wish to cherry-pick one) that could be
applied to your backport branch, except for superficial changes that cause
a (canonical) patch to be rejected.
In principle, you can still apply the patch automatically. You "only"
require a canonical reformatter that preserves line numbering, and a tree
close to the tree on which the patch was based.
The process goes like this:
1. Checkout base tree
2. Reformat all the files mentioned in the bad patch, but confined to
those lines that appear in the patch.
3. Apply the patch and commit
Finally you'd cherry-pick that commit for your backport branch.
In case you receive a patch that's whitespace-damaged, you can do this
first:
1. Checkout base tree
2. Damage all the files mentioned in the bad patch
$ perl -i -p -e 's/\s+/ /g' ...
3. Do the same to the bad patch
4. Apply the bad patch
5. Reformat the files changed by the patch into canonical form
6. Tag that as "B"
7. Checkout base tree
8. Reformat the same files into canonical form
9. Tag that as "A"
10. Produce a good patch
$ git diff A..B
You can now apply the good patch to your branch. Since it is in canonical
form, it may still fail to apply (but see above for the solution).
This second example is not really a job for reviewers/maintainers but it
could be performed automatically by tooling like patchwork.
