Messages in this thread | | | Date | Thu, 16 Dec 2021 16:09:39 -0800 | From | Jakub Kicinski <> | 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@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!
| |