From: "Ævar Arnfjörð Bjarmason" <email@example.com> To: Sebastian Schuberth <firstname.lastname@example.org> Cc: email@example.com, firstname.lastname@example.org Subject: Re: Pain points in Git's patch flow Date: Sun, 18 Apr 2021 22:54:18 +0200 [thread overview] Message-ID: <email@example.com> (raw) In-Reply-To: <firstname.lastname@example.org> 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 , 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. 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.
next prev parent 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: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style List information: http://vger.kernel.org/majordomo-info.html * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --subject='Re: Pain points in Git'\''s patch flow' \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * 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: https://80x24.org/mirrors/git.git 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).