list mirror (unofficial, one of many)
 help / color / mirror / code / Atom feed
From: "Ævar Arnfjörð Bjarmason" <>
To: Sebastian Schuberth <>
Subject: Re: Pain points in Git's patch flow
Date: Sun, 18 Apr 2021 22:54:18 +0200	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>

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

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

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

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.

  reply	other threads:[~2021-04-18 20:54 UTC|newest]

Thread overview: 46+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-04-14  6:13 Jonathan Nieder
2021-04-14  7:22 ` Bagas Sanjaya
2021-04-14  8:02   ` Junio C Hamano
2021-04-14 21:42     ` Junio C Hamano
2021-04-15  8:49   ` Denton Liu
2021-04-15  6:06 ` Junio C Hamano
2021-04-15 15:45 ` Son Luong Ngoc
2021-04-19  2:57   ` Eric Wong
2021-04-19 13:35     ` Theodore Ts'o
2021-04-21 10:19     ` Ævar Arnfjörð Bjarmason
2021-04-28  7:21       ` Eric Wong
2021-04-28  7:05     ` Eric Wong
2021-04-15 18:25 ` Atharva Raykar
2021-04-16 19:50 ` Junio C Hamano
2021-04-16 20:25   ` Junio C Hamano
2021-05-02  5:35   ` ZheNing Hu
2021-04-18  8:29 ` Sebastian Schuberth
2021-04-18 20:54   ` Ævar Arnfjörð Bjarmason [this message]
2021-04-19  2:58     ` Eric Wong
2021-04-19  5:54     ` Sebastian Schuberth
2021-04-19  6:04       ` Sebastian Schuberth
2021-04-19  8:26       ` Ævar Arnfjörð Bjarmason
2021-04-19 19:23         ` Sebastian Schuberth
2021-04-19 22:34           ` Theodore Ts'o
2021-04-20  6:30             ` Sebastian Schuberth
2021-04-20 16:37               ` Theodore Ts'o
2021-04-30 20:45               ` Felipe Contreras
2021-04-20 10:34           ` Ævar Arnfjörð Bjarmason
2021-04-19 19:36       ` Eric Wong
2021-04-19 19:49         ` Sebastian Schuberth
2021-04-19 22:00           ` Konstantin Ryabitsev
2021-05-08  2:10             ` dwh
2021-04-19 21:49       ` Konstantin Ryabitsev
2021-04-19 23:03         ` Stephen Smith
2021-05-08  2:08         ` dwh
2021-05-08  4:41           ` Bagas Sanjaya
2021-04-30 20:58       ` Felipe Contreras
2021-04-21  4:46 ` Daniel Axtens
2021-04-26  2:04 ` brian m. carlson
2021-04-26 14:24   ` Theodore Ts'o
2021-04-26 14:36   ` Ævar Arnfjörð Bjarmason
2021-04-28  7:59   ` Eric Wong
2021-04-28 22:44     ` brian m. carlson
2021-04-30 20:16     ` Felipe Contreras
2021-04-30 20:35   ` Felipe Contreras
2021-04-30 21:09 ` Felipe Contreras

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:

  List information:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \ \ \ \
    --subject='Re: Pain points in Git'\''s patch flow' \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

Code repositories for project(s) associated with this inbox:

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).