Pain points in Git's patch flow

[Ævar Arnfjörð Bjarmason]

On Sun, Apr 18 2021, Sebastian Schuberth wrote:

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

And thank you for participating in the discussion. I think it's
especially valuable to get a viewpoint like yours, i.e. someone who (per
this E-Mail below) gave up in frustration with the current development
flow.

The below isn't meant as a retort, but to hopefully clarify things a
bit.

>>   1. What pain points in the patch flow for git.git are important to
>>      you?
>
> 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 
> account.

I think it's important not to conflate tooling issues with social
issues. It's not that we e.g. couldn't whip up a quick script to
round-robin randomly assign reviewers on the basis of topics Junio has
picked up, which is basically the function of some of these "open a MR
end get on the review train" tools.

Rather it's that it's a volunteer project and people work on what
they're interested in.

So maybe having assigned reviewers would help move things along. But I
wonder if it wouldn't also lead down the rut of PRs/MRs languishing for
months, because the reviewers just want to spend their time in some
other way.

I.e. the design of many of these tools in this regard assumes you have a
workforce, not the cat-herding problem of volunteers working on whatever
strikes their fancy.

> 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 [1], gitgitgadget [2]
> and now patchwork [3] 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 [2] 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.

I think characterizing E-Mail as a "legacy" workflow isn't accurate. All
of these proposed alternatives involve moving away from something that's
a distributed system today (E-Mail infrastructure, local clients), to
what's essentially some website run by a centralized entity, in some
cases proprietary.

Even in cases where the tool itself isn't proprietary (e.g. GitLab
instead of GitHub) using GitHub/GitLab/Gerrit/Atlassian Bitbucket
etc. means having some centralized infrastructure somewhere holding a
bunch of data only the operator of that infrastructure can realistically
access.

So really basic things that are comparatively trivial with E-Mail
(e.g. "I think the search sucks, try another client") run up against a
brick wall with those tools.

And to e.g. as one good example to use (as is the common convention on
this list) git-range-diff to display a diff to the "last rebased
revision" would mean some long feature cycle in those tools, if they're
even interested in implementing such a thing at all.

Because we're E-Mail based that's just something some people started
using (well, it was called "tbdiff" then), some others picked it up etc.

Which is not to say that one can't argue that on balance using those
tools isn't better overall, I'm just responding to the characterization
of E-Mail based development as "legacy", or something those tools
supersede. I think it's better to think of them as orthagonal ways to
reach similar aims.