[PATCH 1/1] scripts: create kernel configuration upgrade script

[Jonas Gorski]

On Wed, 7 Feb 2024 at 12:58, Felix Baumann via openwrt-devel
<openwrt-devel at lists.openwrt.org> wrote:
> Am 7. Februar 2024 11:53:55 MEZ schrieb Jonas Gorski <jonas.gorski at gmail.com>:
> >On Wed, 7 Feb 2024 at 02:48, Elliott Mitchell <ehem+openwrt at m5p.com> wrote:
> >>
> >> Create a script for automating kernel version changes.  This
> >> generates a pair of commits which cause history to remain attached
> >> to all versioned configuration files.
> >
> >Why is this script needed? What exactly does it do? Does it preserve
> >bisectability? How would you use it? I see neither a help message nor
> >any usage examples.
> >
> >Please provide more detailed explanation in the commit message,
> >especially since perl isn't the most common or easy to read language.
> >
> >Regards,
> >Jonas
>
> This might be of help
> <https://lists.openwrt.org/pipermail/openwrt-devel/2023-October/041672.html>
> Elliott linked it in his previous mail.
>
> It explains the problem fairly well.
>
> Short version:
> Right now every new kernel version creates a new kernel config file as a copy of the old one which doesn't preserve the git history which hinders the usage of git blame.

I'm aware of the discussion, my point is that the information /
context should to be in the commit description, not in an external
place with no reference to it. If someone not aware of the email
thread looks at the commit I doubt they will be able to understand the
issue this is trying to solve, or how it is solving it. And since
neither the issue, the solution, nor the script itself are trivial all
three need some sort of explanation in the commit message.

FWIW, git blame also supports a find copies harder (-C) that can
detect copies, not just delete/adds as renames (can be passed multiple
times for even harder finding). Unfortunately it's rather slow and
does not work as well as other git command's find copies harder. Not
sure why. Might be worth investigating.

> git bisect should still work fairly well even without the change.

What does "fairly well" mean? Either this produces commits that work,
or it produces commits that break the build. There is no in between.

Regards,
Jonas