From: Sebastian Schuberth <email@example.com> To: "Ævar Arnfjörð Bjarmason" <firstname.lastname@example.org> Cc: Git Mailing List <email@example.com>, firstname.lastname@example.org Subject: Re: Pain points in Git's patch flow Date: Mon, 19 Apr 2021 21:23:14 +0200 [thread overview] Message-ID: <CAHGBnuMedez4SE-4-JwCcR8k=_FRtjgBdBSEJqshQnVceCvGug@mail.gmail.com> (raw) In-Reply-To: <email@example.com> On Mon, Apr 19, 2021 at 10:26 AM Ævar Arnfjörð Bjarmason <firstname.lastname@example.org> wrote: > > If you send around code patches by mail instead of directly working on > > Git repos plus some UI, that feels to me like serializing a data class > > instance to JSON, printing the JSON string to paper, taking that sheet > > of paper to another PC with a scanner, using OCR to scan it into a > > JSON string, and then deserialize it again to a new data class > > instance, when you could have just a REST API to push the data from on > > PC to the other. > > That's not inherent with the E-Mail workflow, e.g. Linus on the LKML > also pulls from remotes. Yeah, I was vaguely aware of this. To me, the question is why "also"? Why not *only* pull from remotes? What's the feature gap email patches try to close? > It does ensure that e.g. if someone submits patches and then deletes > their GitHub account the patches are still on the ML. Ah, so it's basically just about a backup? That could also be solved differently by forking / syncing Git repos. > To begin with if we'd have used the bugtracker solution from the > beginning we'd probably be talking about moving away from Bugzilla > now. I.e. using those things means your data becomes entangled with the > their opinionated data models. Indeed, it's an art to choose the right tool at the time, and to ensure you're not running into some "vendor-lock-in" if data export is made too hard. And aligning on someone's "opinionated data model" is not necessarily a bad thing, as standardization can also help interoperability and to smoothen workflows. > > Not necessarily. As many of these tools have (REST) APIs, also > > different API clients exist that you could try. > > API use that usually (always?) requires an account/EULA with some entity > holding the data, and as a practical concern getting all the data is > usually some huge number of API requests. I'm not sure how relevant that concern really is, but in any cause it would be irrelevant for a self-hosted solution. > >> 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. > > > > AFAIK Gerrit can already do that. > > Sure, FWIW the point was that you needed Gerrit to implement that, and > to suggest what if they weren't interested. Would you need to maintain a > forked Gerrit? Sorry, I can't follow that. Why would you need to maintain a fork of Gerrit if Gerrit already has the feature you're looking for? Is it a hypothetical question about what to do if Gerrit would not have the feature yet? > Anyway, as before don't take any of the above as arguing, FWIW I > wouldn't mind using one of these websites overall if it helped > development velocity in the project. I appreciate that open mindset of yours here. > I just wanted to help bridge the gap between the distributed E-Mail v.s > centralized website flow. Maybe, instead of jumping into something like an email vs Gerrit discussion, what would help is to get back one step and gather the abstract requirements. Then, with a fresh and unbiased mind, look at all the tools and infrastructure out there that are able to fulfill the needs, and then make a choice. -- Sebastian Schuberth
next prev parent reply other threads:[~2021-04-19 19:23 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 [this message] 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='CAHGBnuMedez4SE-4-JwCcR8k=_FRtjgBdBSEJqshQnVceCvGug@mail.gmail.com' \ --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).