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
