Hi Junio, On Thu, 4 Aug 2016, Junio C Hamano wrote:
> Jeff King <p...@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 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
