linux-kernel - Re: [GIT PULL (not really)] x86/core for v5.16

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAHk-=wiNyR-cAxicOD6nkRQNw-q+uzFvB3hpA-s=7asEKom=og@mail.gmail.com>
Date:   Mon, 1 Nov 2021 14:16:24 -0700
From:   Linus Torvalds <torvalds@...ux-foundation.org>
To:     Borislav Petkov <bp@...e.de>
Cc:     x86-ml <x86@...nel.org>, lkml <linux-kernel@...r.kernel.org>
Subject: Re: [GIT PULL (not really)] x86/core for v5.16

On Mon, Nov 1, 2021 at 3:25 AM Borislav Petkov <bp@...e.de> wrote:
>
> so this is not really a pull request but more of a question on the
> process. I have merged the x86/cc branch into this branch I'm sending to
> you - x86/core - and when I generate the diffstat with git request-pull,
> it adds the changes of the merged branch x86/cc too, of course.
>
> I can doctor the diffstat and the merge message by doing
>
>  git diff --stat ^x86/cc x86_core_for_v5.16_rc1
>
> see below, so that the merged branch's changes are not there.
>
> But I'm not sure if this is the right thing to do. Especially if you do
> not merge x86/cc first - then the below diffstat becomes wrong.

So other developers do this kind of thing fairly regularly, because
they have some "core branch" that does the basic core development
(say, a driver subsystem), and then they have other branches (eg the
lowlevel drivers themselves etc) that depended on the core work but
are sent as individual pull requests to keep the conceptual separation
alive, and make it easier to review.

The way to do it tends to be:

 (a) make it clear that some pull request depends on a previous one,
so that I'm aware of it, and don't do them out of order and get
confused

 (b) when you have a series of pull requests that aren't independent,
create the series of pulls yourself in a temporary tree, and generate
the pull request from that series, with the previous merge always as
the "base".

The reason for (a) is obvious, and the reason for (b) is that then
each pull request automatically gets the right shortlog and diffstat.

Of course, if this is the only time you expect to haev this kind of
dependency, you don't need to have much of a process in place, and a
hacky manual one-time thing like the above works fine too.

And in general, the more independent the pull request can be, the
better. But having two or more branches that have some serial
dependency certainly isn't unheard of or wrong either.  It happens.

             Linus