Pain points in Git's patch flow
sschuberth at gmail.com
Sun Apr 18 18:29:02 AEST 2021
On 2021-04-14 08:13, Jonathan Nieder wrote:
> Those four are important in my everyday life. Questions:
Thanks for bringing up these questions in a dedicated format. I'll take
this as an opportunity to share my thoughts on this topic, which have
accompanied me for quite a while.
> 1. What pain points in the patch flow for git.git are important to
Well, it's email-based. As a result it's error prone to things like
formatting / quoting issues, putting the right people it CC, etc.
I have always wondered why Git core development does not start to make
use of the Git ecosystem that we have by now, esp. in the form of review
tools / platforms like GitHub (via pull-requests), GitLab (via
merge-requests), or Gerrit (via patches). From these, Gerrit would IMO
be the best fit for Git, due to its capability to cope well with
rebase-workflows. Those tools avoid things like formatting / quoting
issues completely, and shift the responsibility of assigning reviewers
from the contributor to the tool, where people can subscribe to code
changes or code ownership can be defined and automatically taken into
Sure, I get that that the contribution workflow to Git core has
historically grown, but what concerns me is that the efforts to "bridge"
the contribution workflow to the "modern world" seem to go into the
wrong direction: Tools like submitgit , gitgitgadget  and now
patchwork  were created / are considered for use to allow the legacy
email path workflow to remain, but also allow more "GUI minded" people
to contribute. While this has worked quite well for some time, and esp.
gitgitgadget  seems to haven gotten popular, I wonder whether it's
now the time to "swap the default", and make a patch / contribution tool
with a GUI the standard, and bridge the legacy workflow by using /
creating tooling that makes it convenient to use those modern tools from
the CLI, instead of the opposite.
> 2. What tricks do you use to get by with those existing pain points?
None. I simply have stopped contributing to Git core, to be frank.
> 3. Do you think patchwork goes in a direction that is likely to help
> with these?
No. To me, this is yet another effort that tries to come up with a
work-around instead of fixing the root cause: It tries to lift the
limitations of an email-based contribution workflow instead of getting
rid of the email-based contribution workflow altogether.
> 4. What other tools would you like to see that could help?
Currently, only Gerrit  comes to my mind, as a complete substitute
for the email-based contribution workflow.
More information about the Patchwork