Re: patch submission process, was Re: [PATCH v6 06/16] merge_recursive: abort properly upon errors

Hi Junio,

On Thu, 4 Aug 2016, Junio C Hamano wrote:

Jeff King [off-list ref] writes:

quoted

Like you, I have occasionally been bitten by Junio doing a fixup, and
then I end up re-rolling, and lose that fixup.

... which usually is caught when I receive the reroll, as I try to apply
to the same base and compare the result with the previous round.

I find it incredibly nice of you to do those fix-ups, sorry to state that
as clearly only now. It's just that I hate to see your time wasted, in
particular when *I* waste it because I missed the fix-ups in `pu`.

quoted

But I think such fixups are a calculated risk. Sometimes they save a
lot of time, both for the maintainer and the contributor, when they
manage to prevent another round-trip of the patch series to the list.

Yes.

FWIW I am more than just willing to spend a little more time on applying
fix-ups and re-rolling patch series (and dual-publishing them via my
public repository), if it helps lighten your burden.

quoted

IOW, if the flow is something like:

  1. Contributor sends patches. People review.

  2. Minor fixups noticed by maintainer, fixed while applying.

This includes different kinds of things:

    a) Trivially correct fixes given in other people's review.

    b) Minor fixups by the maintainer, to code.

    c) Minor fixups by the maintainer, to proposed log message.

    d) "apply --whitespace=fix" whose result I do not even actively
       keep track of.

quoted

  3. Only one small fixup needed from review. Contributor sends
     squashable patch. Maintainer squashes.

then I think that is a net win over sending the whole series again, for
the contributor (who does not bother sending), reviewers (who really
only need to look at the interdiff, which is what that squash is in the
first place), and the maintainer (who can squash just as easily as
re-applying the whole series).

quoted

And that is the flip side. If the flow above does not happen, then step
2 just becomes a pain.

I think I can

 * stop taking 2-a).  This is less work for me, but some
   contributors are leaky and can lose obviously good suggestions,
   so I am not sure if that is an overall win for the quality of the
   end product;

If you had a `git commit --reword` command to touch up commit messages,
would that help you, together with the `git commit --fixup` command for
code changes? The branches in `pu` would have your fix-ups as strictly
separate commits on top of the contributed patches, and the branches would
need to be sent through rebase -i before merging to `next`, of course.

The idea would be to not forget your fixups in subsequent iterations, but
simply rebase them on top of the new iteration.

It would still not solve my problem that there is no convenient way to
jump from your commits in `pu` to the corresponding ones in my local
branch. But that is my problem, not yours.

Ciao,
Dscho