git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: Sebastian Schuberth <sschuberth@gmail.com>
To: git@vger.kernel.org
Cc: patchwork@lists.ozlabs.org
Subject: Re: Pain points in Git's patch flow
Date: Sun, 18 Apr 2021 10:29:02 +0200	[thread overview]
Message-ID: <22a0a383-0ae1-c7d1-75f7-7dfdfe5fb504@gmail.com> (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 [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.

>   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 [4] comes to my mind, as a complete substitute 
for the email-based contribution workflow.

[1] https://github.com/rtyley/submitgit
[2] https://github.com/gitgitgadget/gitgitgadget
[3] http://jk.ozlabs.org/projects/patchwork
[4] https://www.gerritcodereview.com

-- 
Sebastian Schuberth


  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 Pain points in Git's patch flow 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 \
    --in-reply-to=22a0a383-0ae1-c7d1-75f7-7dfdfe5fb504@gmail.com \
    --to=sschuberth@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=patchwork@lists.ozlabs.org \
    /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
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public 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).