lkml.org 
[lkml]   [2021]   [Dec]   [16]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [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@kernel.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!

\
 
 \ /
  Last update: 2021-12-17 01:09    [W:1.446 / U:0.076 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site