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

[Elliott Mitchell]

On Wed, Feb 07, 2024 at 11:53:55AM +0100, Jonas Gorski wrote:
> 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.

Hmm, true.  This might be closer to PoC/WIP status since I was under
major time pressure.  I rather urgently wanted to get this out *before*
the 6.6 configs were added.

Use is supposed to be fairly simple:

```
scripts/kernel_upgrade.pl 6.1 6.6

git merge --ff-only <sha1 given by "Result is commit xxxx" line>
```

The script is *meant* to take care of that second step, but git has so
far been refusing to do that in an automated fashion.  People wanting to
test could instead create a temporary branch at the specified commit and
examine whether they like the result.



On Wed, Feb 07, 2024 at 01:33:11PM +0100, Jonas Gorski wrote:
> On Wed, 7 Feb 2024 at 12:58, Felix Baumann via openwrt-devel
> <openwrt-devel at lists.openwrt.org> wrote:
> >
> > 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.

I'll see about some updating.

> 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.

Rather slow is an understatement.  More than an order of magnitude
slower.  This is the difference between something where you can freely
run the command if you're curious about something you notice.  Versus
something you can occasionally start when you urgently need to examine
a major oddity, but then go off taking a coffee, tea, or other break
while waiting for the result.

Right now `git blame` is too slow to be useful in many places where it
should be used.

> > 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.

Due to the method, inherently a single non-buildable commit is created.
If `git bisect` lands on that, you will need to run `git bisect --skip`
to continue the bisect process.  The commit message could readily be
modified to state this.

I conservatively estimate OpenWRT is generating around 3000 commits per
year.  If the kernel version changes once per year, then there is a
0.03% chance of landing on the commit.  If your typical bisect session
touches 12 commits (this seems excessive) then 0.2% of your bisect
sessions will hit these.

While infinitely greater than zero, that is a worthy trade for making
`git blame` functional on configuration files.


-- 
(\___(\___(\______          --=> 8-) EHM <=--          ______/)___/)___/)
 \BS (    |         ehem+sigmsg at m5p.com  PGP 87145445         |    )   /
  \_CS\   |  _____  -O #include <stddisclaimer.h> O-   _____  |   /  _/
8A19\___\_|_/58D2 7E3D DDF4 7BA6 <-PGP-> 41D1 B375 37D0 8714\_|_/___/5445