From: Eric Wong <email@example.com> To: Sebastian Schuberth <firstname.lastname@example.org> Cc: "Ævar Arnfjörð Bjarmason" <email@example.com>, firstname.lastname@example.org, email@example.com Subject: Re: Pain points in Git's patch flow Date: Mon, 19 Apr 2021 19:36:00 +0000 [thread overview] Message-ID: <20210419193600.GA19186@dcvr> (raw) In-Reply-To: <CAHGBnuOVmzzhgW6GanHBXNb22UW3P1m3i6PJnOUEhYPO76hH4g@mail.gmail.com> Sebastian Schuberth <firstname.lastname@example.org> wrote: > On Sun, Apr 18, 2021 at 10:54 PM Ævar Arnfjörð Bjarmason > <email@example.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 . 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.
next prev parent reply other threads:[~2021-04-19 19:36 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 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 [this message] 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=20210419193600.GA19186@dcvr \ --firstname.lastname@example.org \ --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).