Pain points in Git's patch flow

[Eric Wong]

Sebastian Schuberth <sschuberth at gmail.com> wrote:
> On Sun, Apr 18, 2021 at 10:54 PM Ævar Arnfjörð Bjarmason
> <avarab at gmail.com> wrote:
> 
> > 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.
> 
> To be fair, Git's contribution flow isn't the only reason why I chose
> to stop contributing. Another reason is the very lengthy and tedious
> discussions that too often spark from rather small changes.
> 
> Also, I wouldn't say I "gave up in frustration". It was a mostly
> unemotional decision on which of the many OSS projects I contribute to
> my rare spare time is spent best.

I guess some things aren't for everybody.  When I started
git-svn, I never expected git to be the right tool for others.
I figured most folks could just continue using SVN since they
seem to like centralized things or at least have some sort of
"authority" to look to.

I'm largely uninvolved with git nowadays since I'm reasonably
satisfied with how it works; that and I prefer scripting
languages rather than ahead-of-time languages.

> > Rather it's that it's a volunteer project and people work on what
> > they're interested in.
> 
> Exactly. That's why I believe tooling should allow people to subscribe
> to changes in code areas they're interested in, rather than a
> contributor having to know which subsystem maintainer to put in CC
> (e.g. for gitk changes). At least at the time when I contributed it
> was sometimes hard to move things forward if you didn't reach out to
> the right people.

Fwiw, any public-inbox endpoint with Xapian search enabled lets
you request an Atom feed via "x=A" query parameter.

To watch a particular filename, the "dfn:" prefix may be used.
The prefixes supported for a particular instance are documented in
<https://public-inbox.org/git/_/text/help/>, and you
can watch multiple files by combining with "OR".

https://public-inbox.org/git/?q=dfn:cache.h+OR+dfn:git-send-email.perl&x=A

You can also POST to get a gzipped mboxrd file:

curl -d '' \
  'https://public-inbox.org/git/?q=dfn:cache.h+OR+dfn:git-send-email.perl&x=m'

> > 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.
> 
> That's a good point, I admit I haven't thought of that. Probably
> because I also don't care much. So *does* it really matter? What
> exactly concerns you about a "centralized entity"? Is it the technical
> aspect of a single point of failure, or the political / social aspect
> of being dependent on someone you do not want to get influenced by? I
> guess it's a bit of both.

Yes, both for me.  The political/social aspect is the main
reason I'm involved with DVCS (and a large part of why I'm
involved with free software in general).

> While these concerns could probably be addressed somewhat e.g. by
> multiple independently operated Gerrit servers that are kept in sync,
> I was curious and quickly search for more fitting "truly
> decentralized" solutions, and came across radicle [1]. Just FYI.

I don't think any sort of radicle "flag day" or tool mandate is
going to fly.  I seem to recall at least one prominent Linux
kernel hacker doesn't even use git; though I'm not sure if
that's still the case.

Despite being a DVCS user even pre-git, I'm actually
pessimistic about decentralization protocols that either:

1) rely on planet-destroying proof-of-work schemes

2) will need to reinvent the spam filtering techniques
   of email once they hit critical mass

Email is already well-established with a good amount of small
players, and plain-text is relatively inexpensive.  So it seems
best to build off the only halfway-decentralized thing we have
in wide use, rather than trying to start from scratch.