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" [off-list ref] wrote:

quoted

On Mon, Jun 21, 2021 at 08:26:56AM +1000, Stephen Rothwell wrote:

quoted

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