linux-kernel - Re: [GIT PULL] Networking for 5.16-rc6

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]

Date:   Thu, 16 Dec 2021 15:59:40 -0800
From:   Linus Torvalds <torvalds@...ux-foundation.org>
To:     Jakub Kicinski <kuba@...nel.org>
Cc:     David Miller <davem@...emloft.net>,
        Netdev <netdev@...r.kernel.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        Daniel Borkmann <daniel@...earbox.net>,
        Johannes Berg <johannes@...solutions.net>,
        Kalle Valo <kvalo@...eaurora.org>
Subject: Re: [GIT PULL] Networking for 5.16-rc6

On Thu, Dec 16, 2021 at 3:43 PM Jakub Kicinski <kuba@...nel.org> wrote:
>
> Very strange, I didn't fix it up, redo or anything, push the tree,
> tag, push the tag, git request-pull >> email. And request-pull did
> not complain about anything.

You hadn't pushed the previous case by any chance? 'git request-pull'
does actually end up going off to check the remote end, and maybe it
saw a stale state (because the mirroring to the public side isn't
immediate)?

> While I have you - I see that you drop my SoB at the end of the merge
> message, usually. Should I not put it there?  I put it there because
> of something I read in Documentation/process/...

No, I actually like seeing the sign-off from remote pulls -
particularly in the signed tags where they get saved in the git tree
anyway (you won't _see_ them with a normal 'git log', but you can see
how it's saved off if you do

    git cat-file commit 180f3bcfe3622bb78307dcc4fe1f8f4a717ee0ba

to see the raw commit data).

But I edit them out from the merge message because we haven't
standardized on a format for them, and I end up trying to make my
merges look fairly consistent (I edit just about all merge messages
for whitespace and formatting, as you've probably noticed).

Maybe we should standardize on sign-off messages for merges too, but
they really don't have much practical use.

For a patch, the sign-off chain is really important for when some
patch trouble happens, so that we can cc all the people involved in
merging the patch. And there's obviously the actual copyright part of
the sign-off too.

For a merge? Neither of those are really issues. The merge itself
doesn't add any new code - the sign-offs should be on the individual
commits that do. And if there is a merge problem, the blame for the
merge is solidly with the person who merged it, not some kind of
"merge chain".

So all the real meat is in the history, and the merge commit is about
explaining the high-level "what's going on".

End result: unlike a regular commit, there's not a lot of point for
posterity to have a sign-off chain (which would always be just the two
ends of the merge anyway). End result: I don't see much real reason to
keep the sign-offs in the merge log.

But I _do_ like seeing them in the pull request, because there it's
kind of the "super-sign-off" for the commits that I pull, if you see
what I mean...

Logical? I don't know. But hopefully the above explains my thinking.

                   Linus