From: Sebastian Schuberth <email@example.com> To: firstname.lastname@example.org Cc: email@example.com Subject: Re: Pain points in Git's patch flow Date: Sun, 18 Apr 2021 10:29:02 +0200 [thread overview] Message-ID: <firstname.lastname@example.org> (raw) In-Reply-To: <YHaIBvl6Mf7ztJB3@google.com> 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 > 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. 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.  https://github.com/rtyley/submitgit  https://github.com/gitgitgadget/gitgitgadget  http://jk.ozlabs.org/projects/patchwork  https://www.gerritcodereview.com -- Sebastian Schuberth
next prev parent reply other threads:[~2021-04-18 8:29 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 [this message] 2021-04-18 20:54 ` Ævar Arnfjörð Bjarmason 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 \ --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).