Re: linux-next: Signed-off-by missing for commits in the xfs tree

[Darrick J. Wong]

On Tue, Jun 22, 2021 at 07:27:19AM +1000, Stephen Rothwell wrote:
> Hi Darrick,
> 
> On Mon, 21 Jun 2021 10:12:08 -0700 "Darrick J. Wong" <djwong@xxxxxxxxxx> wrote:
> >
> > On Mon, Jun 21, 2021 at 08:26:56AM +1000, Stephen Rothwell wrote:
> > > 
> > > Commits
> > > 
> > >   742140d2a486 ("xfs: xfs_log_force_lsn isn't passed a LSN")
> > >   e30fbb337045 ("xfs: Fix CIL throttle hang when CIL space used going backwards")
> > >   feb616896031 ("xfs: journal IO cache flush reductions")
> > >   6a5c6f5ef0a4 ("xfs: remove need_start_rec parameter from xlog_write()")
> > >   d7693a7f4ef9 ("xfs: CIL checkpoint flushes caches unconditionally")
> > >   e45cc747a6fd ("xfs: async blkdev cache flush")
> > >   9b845604a4d5 ("xfs: remove xfs_blkdev_issue_flush")
> > >   25f25648e57c ("xfs: separate CIL commit record IO")
> > >   a6a65fef5ef8 ("xfs: log stripe roundoff is a property of the log")
> > > 
> > > are missing a Signed-off-by from their committers.  
> > 
> > <sigh> Ok, I'll rebase the branch again to fix the paperwork errors.
> > 
> > For future reference, if I want to continue accepting pull requests from
> > other XFS developers, what are the applicable standards for adding the
> > tree maintainer's (aka my) S-o-B tags?  I can't add my own S-o-Bs after
> > the fact without rewriting the branch history and changing the commit
> > ids (which would lose the signed tag), so I guess that means the person
> > sending the pull request has to add my S-o-B for me?  Which also doesn't
> > make sense?
> 
> If you want to take a pull request, then use "git pull" (or "git fetch"
> followed by "git merge") which will create a merge commit committed by
> you.  The above commits were applied to your tree by you as patches (or
> rebased) and so need your sign off.  The commits in a branch that you
> just merge into your tree only need the SOBs for their author(s) and
> committer.

I was about to point out all the complaints about when I actually /did/
merge Dave's branch, but I realized that those complaints were actually
because he wasn't consistently signing patches with the same email
address.

Um... do you know if there's a commit hook or something that all of us
can add to spot-check all this stuff?  I would really like to spend my
worry beans on about algorithms and code design, not worrying about how
many signature rules can be bent before LT starts refusing pull requests.

> If you then rebase your tree (with merge commits in it), you need to
> use "git rebase -r" to preserve the merge commits.  alternatively, you
> can rebase the commits you applied as patches and then redo the
> pulls/merges manually.  You generally should not rebase other's work.
> 
> Of course, you should not really rebase a published tree at all (unless
> vitally necessary) - see Documentation/maintainer/rebasing-and-merging.rst

Heh.  That ship has sailed, unfortunately.  If we /really/ care about
maintainers adding their own SoB tags to non-merge commits then I /have/
to rebase.

--D

> 
> -- 
> Cheers,
> Stephen Rothwell