Re: [Ksummit-discuss] Allowing something Change-Id (or something like it) in kernel commits

Dmitry Vyukov
2019-08-27T13:30:25Z

On Tue, Aug 27, 2019 at 12:33 AM Geert Uytterhoeven
<geert@linux-m68k.org> wrote:
>
> Hi Dmitry,
>
> On Tue, Aug 27, 2019 at 2:30 AM Dmitry Vyukov via Ksummit-discuss
> <ksummit-discuss@lists.linuxfoundation.org> wrote:
> > A somewhat related point re UUID/Change-ID.
> > For syzbot (or any other bug tracking system) we want to associate
> > bugs with fixes. It turned out there is no good identity of a change
> > that we could use. Commit hash is an obvious first thing to consider,
> > but (1) it changes in linux-next, (2) sometimes the change is not
> > committed yet when we do the association, (3) it is different when
> > backported to LTS (so not possible to say if a fix is in that stable
> > tree or not).
>
> For (3): LTS commits have "commit <sha1> upstream" in their description
> (perhaps some have "cherry picked from commit <sha1>"?).

A change identification scheme would need to solve all of these. E.g.
non-committed changes look more problematic for anything that uses
commit hashes...

> > We decided to use commit subject, which works to some degree, but also
> > has problems: (1) not necessary unique, (2) sometimes people change
> > subject during backporting (e.g. prepend some prefix), (3) has all the
> > same problems of email clients messing with text (e.g. I can't issue
> > #syz fix command for loo long commit subjects with my email client).
> > Some real UUID/Change-ID would solve all of these problems by giving
> > us capability to refer to changes rather than a commit in a particular
> > tree only.
>
> "git patch-id --stable <sha1>" may help, too.
>
> For quick lookups, you need to generate/append to an index regularly.

It's not me, it's everybody ;)
If I am reading git help correctly, this won't handle changes with
more than 1 version. Also maintainers will be prohibited from doing
any changed to patches during commit.