Re: Pain points in Git's patch flow

From: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
Date: Apr 18, 2021, 20:54 UTC
Message-ID: <87fszn48lh.fsf@evledraar.gmail.com>
In-Reply-To: <22a0a383-0ae1-c7d1-75f7-7dfdfe5fb504@gmail.com>

On Sun, Apr 18 2021, Sebastian Schuberth wrote:

Show 7 quoted lines

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

Show 16 quoted lines

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

Show 12 quoted lines

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