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

[Johannes Schindelin <Johannes.Schindelin@gmx.de>]

Hi Junio,

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

> Jeff King <peff@peff.net> writes:
> 
> > 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`.

> > 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.

> > 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.
> 
> >   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).
> 
> > 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