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