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] [day] [month] [year] [list]

Message-ID: <20211216160939.41e8a2d2@kicinski-fedora-pc1c0hjn.dhcp.thefacebook.com>
Date:   Thu, 16 Dec 2021 16:09:39 -0800
From:   Jakub Kicinski <kuba@...nel.org>
To:     Linus Torvalds <torvalds@...ux-foundation.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, 16 Dec 2021 15:59:40 -0800 Linus Torvalds wrote:
> 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)?

Ah! I know.. I forgot to fetch your tree and used FETCH_HEAD 
in git request-pull which was at bpf :/

Sorry about that!

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

Yup, makes sense, thanks for explaining!