The sr.ht platform linked from the article excites me more than any project in recent memory. It’s a fresh concept, not a Github wannabe like Gitlab.
sr.ht provides hosted (but open source and self-hostable) mini-services: a git server, continuous integration, a task list, a wiki, and a mailing list. These services are designed to work with each other and with existing distributed tools like git and email. If you want to live on the command line and in mutt you can do that, and if you want to use the sr.ht web interface to do some of those tasks you can do that too. Both ways work together.
I always thought that if something is going to replace Github it would have to be a paradigm change, and I think that’s what we’re seeing here. Drew’s project blends the wisdom of the kernel hackers with a tasteful web interface.
Git via mail can be nice but it’s very hard to get used to. It took me ages to set up git send-email correctly, and my problem in the end was that our local router blocked SMTP connections to non-whitelisted servers. This is just one way it can go wrong. I can inagine there are many more.
And just another minor comment: Everyone knows that Git is decentralized (not federated, btw.), the issue is GitHub, ie the service that adds a certain something to version control, like profiles, stars, commit-stats, fork-counts, followers,etc. A one-sided, technical perspective ignores all of these things as useless and unnecessary – falsely. Centralized platforms have a unfair benefit in this perspective, since there’s only one voice, one claim and no way to question it. One has to assume they make sure that the accounts are all real, and not spam-bots, otherwise nothing makes sense.
To overcome this issue, is the big task. And Email, which is notoriously bad at any identity validation, might not be the best thing. To be fair, ActivityPub, currently isn’t either, but the though that different services and platforms could interoperate (and some of these might even support a email-interface) seems at the very least interesting to me.
Article author here. As begriffs said, I propose email as the underlying means of federating web forges, as opposed to ActivityPub. The user experience is very similar and users who don’t know how to or don’t want to use git send-email don’t have to.
Everyone knows that Git is decentralized (not federated, btw.)
The point of this article is to show that git is federated. There are built in commands which federate git using email (a federated system) as the transport.
GitHub, ie the service that adds a certain something to version control, like profiles, stars, commit-stats, fork-counts, followers,etc. A one-sided, technical perspective ignores all of these things as useless and unnecessary – falsely
Profiles can live on sr.ht, but on any sr.ht instance, or any instance of any other forge software which federates with email. A person would probably still have a single canonical place they live on, and a profile there which lists their forks of software from around the net. Commit stats are easily generated on such a platform as well. Fork counts and followers (stars?) I find much less interesting, they’re just ego stroking and should be discarded if technical constraints require.
I don’t think that’s a strong argument in favor of git being federated. I don’t think it matters either.
Git in of itself does not care about the transport. It does not care whether you use HTTP, git:// or email to bring your repo up to date. You can even use an USB stick.
I’d say git is communication format agnostic, federation is all about standardizing communication. Using email with git is merely another way to pipe git I/O, git itself does not care.
Yes but ultimately both do not require nor care about federation itself.
send-email is IMO more of a utility function, git am or format-patch, which as you mention go to mailboxes, have nothing to do with email’s federated nature. Neither is SMTP tbh, atleast on the Client-Server side.
They’re convenience scripts that do the hard part of writing patches in mails for you, you can also just have your mailbox on a usb stick and transport it that way. And the SMTP doesn’t need to go elsewhere either.
I guess the best comparison is that this script is no more than a frontend for Mastodon. The Frontend of Mastodon isn’t federated either, Mastodon itself is. Federation is the server-to-server part. That’s the part we care about. But git doesn’t care about that.
I see what you’re getting at. I have to concede that you are correct in a pedantic sense, but in a practical sense none of what you’re getting at matters. In a practical sense, git is federated via email.
That various email utilities are included seems more like a consequence of email being the preferred workflow of git developers. I don’t see how that makes it the canonical workflow compared to pulling from remotes via http or ssh, git has native support for both after all.
I belive that @tscs37 already showed that Git is distributed, since all nodes are equal (no distinction between clinets and servers), while a git networks can be structured in a federated fashion, ir even in a centralized one. What the transport medium has to do with this is still unclear in my view.
Fork counts and followers (stars?) I find much less interesting, they’re just ego stroking and should be discarded if technical constraints require
That’s exactly my point. GitHub offers a unit-standard, and easily recognisable and readable (simply because everyone is used to it). This has a value and ultimately a relevance, that can’t just be ignored, even if this reason is nonsense. It would just be another example of technical naïve.
I’ve shown my sympathy for ideas like these before, ad I most certainly don’t want to make the impression of a GitHub apologist. All I want to remind people is that the Social aspect beyond necessity (builds, issue trackers, …) are all things one has to seriously consider and tackle when one is interested in offering an alternative to GitHub, with any serious ambitions.
I don’t think sr.ht has to please everyone. People who want these meaningless social features will probably be happier on some other platform, while the veterans are getting work done.
I’m fine with people using mailing-list oriented solutions (the elitism might be a bit off-putting, but never mind). I just don’t think that it’s that much better than the GitPub idea.
People who want these meaningless social features will probably be happier on some other platform, while the veterans are getting work done.
If having these so-called “meaningless social features” helps a project thrive, attract contributers and new users, I wouldn’t conciser these meaningless. But if that’s not what you are interested in, that’s just ok.
our local router blocked SMTP connections to non-whitelisted servers
The article says that sr.ht can optionally send the emails for you, no git send-mail required: “They’ll enter an email address (or addresses) to send the patch(es) to, and we’ll send it along on their behalf.”
Also what mail transfer agent were you pointing git send-mail at? You can have it send through gmail/fastmail/etc servers – would your router block that?
GitHub […] adds a certain something to version control, like profiles, stars, commit-stats, fork-counts, followers
How about mirroring code on github to collect stars? Make it a read-only mirror by disabling issues and activating the pull request rejection bot. Git, Linux, and Postgres do this, and probably other projects do too.
Email […] is notoriously bad at any identity validation
Do SPF, DKIM and DMARC make this no longer true, or are there still ways to impersonate people?
Also what mail transfer agent were you pointing git send-mail at?
Fastmail. Was too esoteric for the default settings of my router. And if it weren’t for support, I would have never guessed that that was the issue, since the whole interface is so alien to most people (just like the questions: did I send the right commits, is my message formatted correctly, etc.)
How about mirroring code on github to collect stars? Make it a read-only mirror by disabling issues and activating the pull request rejection bot. Git, Linux, and Postgres do this, and probably other projects do too.
I’m not saying it’s perfect (again, I’m no GitHub apologist) – my point is that it isn’t irrelevant!
Do SPF, DKIM and DMARC make this no longer true, or are there still ways to impersonate people?
Yes, if someone doesn’t use these things. And claiming “oh, but they just should” is again raising the entry barrier, which is just too high the way it already would be.
Yes, if someone doesn’t use these things. And claiming “oh, but they just should” is again raising the entry barrier, which is just too high the way it already would be.
This doesn’t damn the whole idea, it just shows us where open areas of development are.
Git via email sounds like hell to me. I’ve tried to find some articles that evangelize the practice of doing software development tasks through email, but to no avail. What is the allure of approaches like this? What does it add to just using git by itself?
While my general experience with git email is bad (it’s annoying to set up, especially in older versions and I don’t like it’s interface too much), my experience of interaction with projects that do this was generally good. You send a patch, you get review, you send a new, self-contained patch, attached to the same thread… etc, in parallel to the rest of the project discussion. It’s a different flavour, but with a project that is used to the flow, it can really be quite pleasing.
I think the selling point is precisely that it doesn’t add anything else. Creating a PR involves more steps and context changes than git-format-patch git-send-mail.
I have little experience using the mailing list flow, but when I had to do so (because the project required it) I found it very easy to use and better for code reviews.
Simply, it’s “create a fork and push your changes to it”. But also consider that it’s…
Open a web browser
Register for a GitHub account
Confirm your email address
Fork the repository
Push your changes to the fork
Open a pull request
In this workflow, you switched between your terminal, browser, mail client, browser, terminal, and browser before the pull request was sent.
With git send-email, it’s literally just git send-email HEAD^ to send the last commit, then you’re prompted for an email address, which you can obtain from git blame or the mailing list mentioned in the README. You can skip the second step next time by doing git config sendemail.to someone@example.org. Bonus: no proprietary software involved in the send-email workflow.
Also github pull requests involve more git machinery than is necessary. Most people, when they open a PR, choose to make a feature branch in their fork from which to send the PR, rather than sending from master. The PR exposes the sender’s local branching choices unnecessarily. Then, for each PR, github creates more refs on the remote, so you end up having lots stuff laying around (try running git ls-remote | grep pull).
Compare that with the idea that if you want to send a code change, just mail the project a description (diff) of the change. We all must be slightly brainwashed when that doesn’t seem like the most obvious thing to do.
In fact the sender wouldn’t even have to use git at all, they could download a recent code tarball (no need to clone the whole project history), make changes and run the diff command… Might not be a great way to do things for ongoing contributions, but works for a quick fix.
Of course opening the PR is just the start of the future stymied github interactions.
To send email, you also have to have an email address. If we are doing a fair comparison, that should be noted as well. Granted, it is much more likely that someone has an email address than a GitHub account, but the wonderful thing about both is that you only have to set them up once. So for this reason, it would be a bit more fair if the list above started from step four.
Now, if I have GitHub integration in my IDE (which is not an unreasonable thing to assume), then I do not need to leave the IDE at all, and I can fork, push, and open a PR (case in point, Emacs and Magithub can do this). I can also do all of this on GitHub, never leaving my browser. I don’t have to figure out where to send an email, because it automatically sends the PR to the repo I forked from. I don’t even need to open a shell and deal with the commandline. I can do everything with shortcuts and a little bit of mousing around, in both the IDE and the browser case.
Even as someone who is familiar with the commandline, and is sufficiently savvy with e-mail (at one point I was subscribed to debian-bugs-dist AND LKML, among other things, and had no problem filtering out the few bits I needed), I’d rather work without having to send patches, using Magit + magithub instead. It’s better integrated, hides uninteresting details from me, so I can get done with my work faster. It works out of the box. git send-email does not, it requires a whole lot of set up per repo.
Furthermore, with e-mail, you have to handle replies, have a firm grip on your inbox. That’s an art on its own. No such issue with GitHub.
With this in mind, the remaining benefit of git send-email is that it does not involve a proprietary platform. For a whole lot of people, that’s not an interesting property.
To send email, you also have to have an email address. If we are doing a fair comparison, that should be noted as well.
I did note this:
then you’re prompted for an email address, which you can obtain from git blame or the mailing list mentioned in the README
Magit + magithub […] works out of the box
Only if you have a GitHub account and authorize it. Which is a similar amount of setup, if not more, compared to setting up git send-email with your SMTP info.
git send-email does not, it requires a whole lot of set up per repo
You only have to put your SMTP creds in once. Then all you have to do per-repo is decide where to send the email to. How is this more work than making a GitHub fork? All of this works without installing extra software to boot.
then you’re prompted for an email address, which you can obtain from git blame or the mailing list mentioned in the README
With GitHub, I do not need to obtain any email address, or dig it out of a README. It sets things up automatically for me so I can just open a PR, and have everything filled out.
Only if you have a GitHub account and authorize it. Which is a similar amount of setup, if not more, compared to setting up git send-email with your SMTP info.
Lets compare:
e-mail:
Clone repository
Do my business
Figure out where to send e-mail to.
git config so I won’t have to figure it out ever again.
git send-email
magithub:
clone repo
do my business
fork the repo
push changes
open PR
The first two steps are pretty much the same, both are easily assisted by my IDE. The difference starts from step 3, because my IDE can’t figure out for me where to send the email. That’s a manual step. I can create a helper that makes it easier for me to do step 4 once I have the address, but that’s about it. For the magithub case, step 3 is SPC g h f; step 4 SPC g s p u RET; step 5 SPC g h p, then edit the cover letter, and , c (or C-c) to finish it up and send it. You can use whatever shortcuts you set up, these are mine. Nothing to figure out manually, all automated. All I have to do is invoke a shortcut, edit the cover letter (the PR’s body), and I’m done.
I can even automate the clone + fork part, and combine push changes + open PR, so it becomes:
fork & clone repo (or clone if already forked)
do my business
push changes & open PR
Can’t do such automation with e-mailed patches.
I’m not counting GitHub account authorization, because that’s about the same complexity as configuring auth for my SMTP, and both have to be done only once. I’m also not counting registering a GitHub account, because that only needs to be done once, and you can use it forever, for any GitHub-hosted repo, and takes about a minute, a miniscule amount compared to doing actual development.
Again, the main difference is that for the e-mail workflow, I have to figure out the e-mail address, a process that’s longer than forking the repo and pushing my changes, and a process that can’t be automated to the point of requiring a single shortcut.
Then all you have to do per-repo is decide where to send the email to. How is this more work than making a GitHub fork?
Creating a GitHub fork is literally one shortcut, or one click in the browser. If you can’t see how that is considerably easier than digging out email addresses from free-form text, then I have nothing more to say.
And we haven’t talked about receiving comments on the email yet, or accepting patches. Oh boy.
With GitHub, I do not need to obtain any email address, or dig it out of a README. It sets things up automatically for me so I can just open a PR, and have everything filled out.
You already had to read the README to figure out how to compile it, and check if there was a style guide, and review guidelines for contribution…
Lets compare
Note that your magithub process is the same number of steps but none of them have “so I won’t have to figure it out ever again”, which on the email process actually eliminates two of your steps.
Your magithub workflow looks much more complicated, and you could use keybindings to plug into send-email as well.
Your magithub workflow looks much more complicated, and you could use keybindings to plug into send-email as well.
I just remembered a good illustration that might explain my stance a bit better. My wife, a garden engineer, was able to contribute to a few projects during Hacktoberfest (three years in a row now), with only a browser and GitHub for Windows at hand. She couldn’t have done it via e-mail, because the only way she can use her email is via her smart phone, or GMail’s web interface. She knows nothing else, and is not interested in learning anything else either, because these perfectly suit her needs. Yet, she was able to discover projects (by looking at what I contributed to, or have starred), search for TODOs or look at existing issues, fork a repo, write some documentation, and submit a PR. She could have done it all from a web browser, but I set up GitHub for Windows for her - in hindsight, I should have let her just use the browser. We’ll do that this year.
She doesn’t know how to use the command-line, has no desire, and no need to learn it. Her email handling is… something that makes me want to scream (no filters, no labels, no folders - one big, unorganized inbox), but it suits her, and as such, she has no desire to change it in any way.
She doesn’t know Emacs, or any IDE for that matter, and has no real need for them, either.
Yet, her contributions were well received, they were useful, and some are still in place today, unchanged. Why? Because GitHub made it easy for newcomers to contribute. They made it so that contributing does not require them to use anything else but GitHub. This is a pretty strong selling point for many people, that using GitHub (and similar solutions) does not affect any other tool or service they use. It’s distinct, and separate.
Not all projects have work for unskilled contributors. Why should we cater to them (who on the whole do <1% of the work) at the expense of the skilled contributors? Particularly the most senior contributors, who in practice do 90% of the work. We don’t build houses with toy hammers so that your grandma can contribute.
I’m not saying we shouldn’t make tools which accomodate everyone. I’m saying we should make tools that accomodate skilled engineers and build simpler tools on top of that. Thus, the skilled engineers are not slowed down and the greener contributors can still get work done. Then, there’s a path for newer users to become more exposed to more powerful tools and more smoothly become senior contributors themselves.
You need to get this point down if you want me to keep entertaining a discussion with you: you can build the same easy-to-use UX and drive it with email.
I’m not saying we shouldn’t make tools which accomodate everyone. I’m saying we should make tools that accomodate skilled engineers and build simpler tools on top of that.
I was under the impression that git + GitHub are exactly these. Git and git send-email for those who prefer those style, GitHub for those who prefer that. The skilled engineers can use the powerful tools they have, while those with a different skillset can use GitHub. All you need is willingness to work with both.
you can build the same easy-to-use UX and drive it with email.
I’m not questioning you can build something very similar, but as long as e-mail is the only driving power behind it, there will be plenty of people who will turn to some other tool. Because filtering email is something you and I can easily do, but many can’t, or aren’t willing to. Not when there are alternatives that don’t require them to do extra work.
Mind you, I consider myself a skilled engineer, and I mainly use GitHub/GitLab APIs, because I don’t have to filter e-mail, nor parse the info in them, the API serves me data I can use in an easier manner. From an integrator point of view, this is golden. If, say, an Emacs integration starts with “Set up your email so mail with these properties are routed here”, that’s not a good user experience. And no, I don’t want to use my MUA to work with git, because magit is a much better, much more powerful tool for that, and I value my productivity.
I’m not questioning you can build something very similar, but as long as e-mail is the only driving power behind it, there will be plenty of people who will turn to some other tool.
I’m pretty sure the whole point would be that the “shiny UI” tool would not expose email to the user at all – so the “plenty of people” wouldn’t leave because they wouldn’t know the difference.
So…. pretty much GitHub/GitLab/Gitea 2.0, but with the added ability to open PRs by email (to cater to that workflow), and a much less reliable foundation?
You already had to read the README to figure out how to compile it, and check if there was a style guide, and review guidelines for contribution…
I might have read the README, or skimmed it. But not to figure out how to compile - most languages have a reasonably standardised way of doing things. If a particular project does not follow that, I will most likely just stop caring unless I really, really need to compile it for one reason or another. For style, I hope they have tooling to enforce it, or at least check it, so I don’t have to read long documents and keep it in my head. I have more important things to store there than things that should be automated.
I would likely read the contributing guidelines, but I won’t memorize it, and I certainly won’t try to remember an e-mail address. I might remember where to find it, but it will still be a manual process. Not a terribly long process, but noticeably longer than not having to do it at all.
Note that your magithub process is the same number of steps but none of them have “so I won’t have to figure it out ever again”, which on the email process actually eliminates two of your steps.
Because there’s nothing for me to figure out at all, ever (apart from what repo to clone & fork, but that’s a common step between the two workflows).
Your magithub workflow looks much more complicated
How is it more complicated? Clone, work, fork, push, open PR (or clone+fork, work, push+PR), of which all but “work” is heavily assisted. None of it requires me to look anything up, anywhere.
and you could use keybindings to plug into send-email as well.
And I do, when I’m dealing with projects that use an e-mail workflow. It’s not about shortcuts, but what can be automated, what the IDE can do instead of requiring me to do it.
You can do this and even more!
You can, if you can extract the address to send patches to automatically. You can build something that does that, but then the automation is tied to that platform, just like the PRs are tied to GitHub/GitLab/whatever.
And again, this is just about sending a patch/opening a PR. There’s so much more PRs provide than that. Some of that, you can do with e-mail. Most of it, you can build on top of e-mail. But once you build something on top of e-mail, you no longer have an e-mail workflow, you have a different platform with which you can interact via e-mail. Think issues, labels for them, reviews (with approvals, rejection, etc - all of which must be discoverable by programs reliably), new commits, rebases and whatnot… yeah, you can build all of this on top of e-mail, and provide a web UI or an API or tools or whatever to present the current state (or any prior state). But then you built a platform which requires special tooling to use to its full potential, and you’re not much better than GitHub. You might build free software, but then there’s GitLab, Gitea, Gogs and a whole lot of others which do many of these things already, and are almost as easy to use as GitHub.
I’ve worked with patches sent via e-mail quite a bit in the past. One can make it work, but it requires a lot of careful thought and setup to make it convenient. I’ll give a few examples!
With GitHub and the like, it is reasonably easy to have an overview of open pull requests, without subscribing to a mailing list, or browsing archives. An open PR list is much easier to glance at and have a rough idea than a mailing list. PRs can have labels to help in figuring out what part of the repo they touch, or what state they are in. They can have CI states attached. At a glance, you get a whole lot of information. With a mailing list, you don’t have that. You can build something on top of e-mail that gives you a similar overview, but then you are not using e-mail only, and will need special tooling to process the information further (eg, to limit open PRs to those that need a review, for example).
With GitHub and the like, you can subscribe to issues and pull requests, and you’ll get notifcations about those and those alone. With a mailing list, you rarely have that option, and must do filtering on your own, and hope that there’s a reasonable convention that allows you to do so reliably.
There’s a whole lot of other things that these tools provide over plain patches over email. Like I said before, most - if not all - of that can be built on top of e-mail, but to achieve the same level of convenience, you will end up with an API that isn’t e-mail. And then you have Yet Another Platform.
How is it more complicated? Clone, work, fork, push, open PR (or clone+fork, work, push+PR)
Because the work for the send-email approach is: clone, work, git send-email. This is fewer steps and is therefore less complicated. Not to mention that as projects become more decentralized as they move away from GItHub, the registration process doesn’t go away and starts recurring for every new forge or instance of a forge you work with.
But once you build something on top of e-mail, you no longer have an e-mail workflow, you have a different platform with which you can interact via e-mail. Think issues, labels for them, reviews (with approvals, rejection, etc - all of which must be discoverable by programs reliably), new commits, rebases and whatnot…
Yes, that’s what I’m advocating for.
But then you built a platform which requires special tooling to use to its full potential, and you’re not much better than GitHub
No, I’m proposing all of this can be done with a very similar UX on the web and be driven by email underneath.
PRs can have labels to help in figuring out what part of the repo they touch, or what state they are in. They can have CI states attached.
So let’s add that to mailing list software. I explicitly acknoweldge the shortcomings of mail today and posit that we should invest in these areas rather than rebuilding from scratch without an email-based foundation. But none of the problems you bring up are problems that can’t be solved with email. They’re just problems which haven’t been solved with emails. Problems I am solving with emails. Read my article!
but then you are not using e-mail only, and will need special tooling to process the information further (eg, to limit open PRs to those that need a review, for example).
So what? Why is this even a little bit of a problem? What the hell?
With GitHub and the like, you can subscribe to issues and pull requests, and you’ll get notifcations about those and those alone.
You can’t subscribe to issues or pull requests, you have to subscribe to both, plus new releases. Mailing lists are more flexible in this respect. There are often separate thing-announce, thing-discuss (or thing-users), and thing-dev mailing lists which you can subscribe to separately depending on what you want to hear about.
Like I said before, most - if not all - of that can be built on top of e-mail, but to achieve the same level of convenience, you will end up with an API that isn’t e-mail.
No, you won’t. That’s simply not how this works.
Look, we’re just not on the same wavelength here. I’m not going to continue diving into this ditch of meaningless argument. You keep using whatever you’re comfortable with.
Using GitHub requires pushing to different repository and then opening the PR on the GitHub Interface, which is a context change. The git-send-mail would be equivalent to sending the PR.
git-send-email is only one step, akin to opening the PR, no need to push to a remote repository. And from the comfort of your development environment. (Emacs in my case)
The sr.ht platform linked from the article excites me more than any project in recent memory. It’s a fresh concept, not a Github wannabe like Gitlab.
sr.ht provides hosted (but open source and self-hostable) mini-services: a git server, continuous integration, a task list, a wiki, and a mailing list. These services are designed to work with each other and with existing distributed tools like git and email. If you want to live on the command line and in mutt you can do that, and if you want to use the sr.ht web interface to do some of those tasks you can do that too. Both ways work together.
I always thought that if something is going to replace Github it would have to be a paradigm change, and I think that’s what we’re seeing here. Drew’s project blends the wisdom of the kernel hackers with a tasteful web interface.
Git via mail can be nice but it’s very hard to get used to. It took me ages to set up git send-email correctly, and my problem in the end was that our local router blocked SMTP connections to non-whitelisted servers. This is just one way it can go wrong. I can inagine there are many more.
And just another minor comment: Everyone knows that Git is decentralized (not federated, btw.), the issue is GitHub, ie the service that adds a certain something to version control, like profiles, stars, commit-stats, fork-counts, followers,etc. A one-sided, technical perspective ignores all of these things as useless and unnecessary – falsely. Centralized platforms have a unfair benefit in this perspective, since there’s only one voice, one claim and no way to question it. One has to assume they make sure that the accounts are all real, and not spam-bots, otherwise nothing makes sense.
To overcome this issue, is the big task. And Email, which is notoriously bad at any identity validation, might not be the best thing. To be fair, ActivityPub, currently isn’t either, but the though that different services and platforms could interoperate (and some of these might even support a email-interface) seems at the very least interesting to me.
Article author here. As begriffs said, I propose email as the underlying means of federating web forges, as opposed to ActivityPub. The user experience is very similar and users who don’t know how to or don’t want to use git send-email don’t have to.
The point of this article is to show that git is federated. There are built in commands which federate git using email (a federated system) as the transport.
Profiles can live on sr.ht, but on any sr.ht instance, or any instance of any other forge software which federates with email. A person would probably still have a single canonical place they live on, and a profile there which lists their forks of software from around the net. Commit stats are easily generated on such a platform as well. Fork counts and followers (stars?) I find much less interesting, they’re just ego stroking and should be discarded if technical constraints require.
I don’t think that’s a strong argument in favor of git being federated. I don’t think it matters either.
Git in of itself does not care about the transport. It does not care whether you use HTTP, git:// or email to bring your repo up to date. You can even use an USB stick.
I’d say git is communication format agnostic, federation is all about standardizing communication. Using email with git is merely another way to pipe git I/O, git itself does not care.
git send-email literally logs into SMTP and sends a patch with it.
git am and git format-patch explicitly refer to mailboxes.
Email is central to the development of Linux and git itself, the two projects git is designed for. Many git features are designed with email in mind.
Yes but ultimately both do not require nor care about federation itself.
send-email is IMO more of a utility function, git am or format-patch, which as you mention go to mailboxes, have nothing to do with email’s federated nature. Neither is SMTP tbh, atleast on the Client-Server side.
They’re convenience scripts that do the hard part of writing patches in mails for you, you can also just have your mailbox on a usb stick and transport it that way. And the SMTP doesn’t need to go elsewhere either.
I guess the best comparison is that this script is no more than a frontend for Mastodon. The Frontend of Mastodon isn’t federated either, Mastodon itself is. Federation is the server-to-server part. That’s the part we care about. But git doesn’t care about that.
I see what you’re getting at. I have to concede that you are correct in a pedantic sense, but in a practical sense none of what you’re getting at matters. In a practical sense, git is federated via email.
That various email utilities are included seems more like a consequence of email being the preferred workflow of git developers. I don’t see how that makes it the canonical workflow compared to pulling from remotes via http or ssh, git has native support for both after all.
I belive that @tscs37 already showed that Git is distributed, since all nodes are equal (no distinction between clinets and servers), while a git networks can be structured in a federated fashion, ir even in a centralized one. What the transport medium has to do with this is still unclear in my view.
That’s exactly my point. GitHub offers a unit-standard, and easily recognisable and readable (simply because everyone is used to it). This has a value and ultimately a relevance, that can’t just be ignored, even if this reason is nonsense. It would just be another example of technical naïve.
I’ve shown my sympathy for ideas like these before, ad I most certainly don’t want to make the impression of a GitHub apologist. All I want to remind people is that the Social aspect beyond necessity (builds, issue trackers, …) are all things one has to seriously consider and tackle when one is interested in offering an alternative to GitHub, with any serious ambitions.
I don’t think sr.ht has to please everyone. People who want these meaningless social features will probably be happier on some other platform, while the veterans are getting work done.
I’m fine with people using mailing-list oriented solutions (the elitism might be a bit off-putting, but never mind). I just don’t think that it’s that much better than the GitPub idea.
If having these so-called “meaningless social features” helps a project thrive, attract contributers and new users, I wouldn’t conciser these meaningless. But if that’s not what you are interested in, that’s just ok.
The article says that sr.ht can optionally send the emails for you, no git send-mail required: “They’ll enter an email address (or addresses) to send the patch(es) to, and we’ll send it along on their behalf.”
Also what mail transfer agent were you pointing git send-mail at? You can have it send through gmail/fastmail/etc servers – would your router block that?
How about mirroring code on github to collect stars? Make it a read-only mirror by disabling issues and activating the pull request rejection bot. Git, Linux, and Postgres do this, and probably other projects do too.
Do SPF, DKIM and DMARC make this no longer true, or are there still ways to impersonate people?
Fastmail. Was too esoteric for the default settings of my router. And if it weren’t for support, I would have never guessed that that was the issue, since the whole interface is so alien to most people (just like the questions: did I send the right commits, is my message formatted correctly, etc.)
I’m not saying it’s perfect (again, I’m no GitHub apologist) – my point is that it isn’t irrelevant!
Yes, if someone doesn’t use these things. And claiming “oh, but they just should” is again raising the entry barrier, which is just too high the way it already would be.
This doesn’t damn the whole idea, it just shows us where open areas of development are.
Git via email sounds like hell to me. I’ve tried to find some articles that evangelize the practice of doing software development tasks through email, but to no avail. What is the allure of approaches like this? What does it add to just using
gitby itself?I tried to collect the pros and cons in this article: https://begriffs.com/posts/2018-06-05-mailing-list-vs-github.html
I also spoke about this at length in a previous article:
https://drewdevault.com/2018/07/02/Email-driven-git.html
While my general experience with git email is bad (it’s annoying to set up, especially in older versions and I don’t like it’s interface too much), my experience of interaction with projects that do this was generally good. You send a patch, you get review, you send a new, self-contained patch, attached to the same thread… etc, in parallel to the rest of the project discussion. It’s a different flavour, but with a project that is used to the flow, it can really be quite pleasing.
I think the selling point is precisely that it doesn’t add anything else. Creating a PR involves more steps and context changes than git-format-patch git-send-mail.
I have little experience using the mailing list flow, but when I had to do so (because the project required it) I found it very easy to use and better for code reviews.
I’m not sure I understand. What steps are removed that would otherwise be required?
Simply, it’s “create a fork and push your changes to it”. But also consider that it’s…
In this workflow, you switched between your terminal, browser, mail client, browser, terminal, and browser before the pull request was sent.
With git send-email, it’s literally just
git send-email HEAD^to send the last commit, then you’re prompted for an email address, which you can obtain from git blame or the mailing list mentioned in the README. You can skip the second step next time by doinggit config sendemail.to someone@example.org. Bonus: no proprietary software involved in the send-email workflow.Also github pull requests involve more git machinery than is necessary. Most people, when they open a PR, choose to make a feature branch in their fork from which to send the PR, rather than sending from master. The PR exposes the sender’s local branching choices unnecessarily. Then, for each PR, github creates more refs on the remote, so you end up having lots stuff laying around (try running
git ls-remote | grep pull).Compare that with the idea that if you want to send a code change, just mail the project a description (diff) of the change. We all must be slightly brainwashed when that doesn’t seem like the most obvious thing to do.
In fact the sender wouldn’t even have to use git at all, they could download a recent code tarball (no need to clone the whole project history), make changes and run the diff command… Might not be a great way to do things for ongoing contributions, but works for a quick fix.
Of course opening the PR is just the start of the future stymied github interactions.
In my case I tend to also perform steps:
man git-remoteto see how to point my local clone (with the changes) to my GitHub forkgit remotecommandsman git-pushto see how to send my changes to the fork rather than the original repoTo send email, you also have to have an email address. If we are doing a fair comparison, that should be noted as well. Granted, it is much more likely that someone has an email address than a GitHub account, but the wonderful thing about both is that you only have to set them up once. So for this reason, it would be a bit more fair if the list above started from step four.
Now, if I have GitHub integration in my IDE (which is not an unreasonable thing to assume), then I do not need to leave the IDE at all, and I can fork, push, and open a PR (case in point, Emacs and Magithub can do this). I can also do all of this on GitHub, never leaving my browser. I don’t have to figure out where to send an email, because it automatically sends the PR to the repo I forked from. I don’t even need to open a shell and deal with the commandline. I can do everything with shortcuts and a little bit of mousing around, in both the IDE and the browser case.
Even as someone who is familiar with the commandline, and is sufficiently savvy with e-mail (at one point I was subscribed to debian-bugs-dist AND LKML, among other things, and had no problem filtering out the few bits I needed), I’d rather work without having to send patches, using Magit + magithub instead. It’s better integrated, hides uninteresting details from me, so I can get done with my work faster. It works out of the box.
git send-emaildoes not, it requires a whole lot of set up per repo.Furthermore, with e-mail, you have to handle replies, have a firm grip on your inbox. That’s an art on its own. No such issue with GitHub.
With this in mind, the remaining benefit of
git send-emailis that it does not involve a proprietary platform. For a whole lot of people, that’s not an interesting property.I did note this:
Only if you have a GitHub account and authorize it. Which is a similar amount of setup, if not more, compared to setting up git send-email with your SMTP info.
You only have to put your SMTP creds in once. Then all you have to do per-repo is decide where to send the email to. How is this more work than making a GitHub fork? All of this works without installing extra software to boot.
With GitHub, I do not need to obtain any email address, or dig it out of a README. It sets things up automatically for me so I can just open a PR, and have everything filled out.
Lets compare:
e-mail:
magithub:
The first two steps are pretty much the same, both are easily assisted by my IDE. The difference starts from step 3, because my IDE can’t figure out for me where to send the email. That’s a manual step. I can create a helper that makes it easier for me to do step 4 once I have the address, but that’s about it. For the magithub case, step 3 is
SPC g h f; step 4SPC g s p u RET; step 5SPC g h p, then edit the cover letter, and, c(orC-c) to finish it up and send it. You can use whatever shortcuts you set up, these are mine. Nothing to figure out manually, all automated. All I have to do is invoke a shortcut, edit the cover letter (the PR’s body), and I’m done.I can even automate the clone + fork part, and combine push changes + open PR, so it becomes:
Can’t do such automation with e-mailed patches.
I’m not counting GitHub account authorization, because that’s about the same complexity as configuring auth for my SMTP, and both have to be done only once. I’m also not counting registering a GitHub account, because that only needs to be done once, and you can use it forever, for any GitHub-hosted repo, and takes about a minute, a miniscule amount compared to doing actual development.
Again, the main difference is that for the e-mail workflow, I have to figure out the e-mail address, a process that’s longer than forking the repo and pushing my changes, and a process that can’t be automated to the point of requiring a single shortcut.
Creating a GitHub fork is literally one shortcut, or one click in the browser. If you can’t see how that is considerably easier than digging out email addresses from free-form text, then I have nothing more to say.
And we haven’t talked about receiving comments on the email yet, or accepting patches. Oh boy.
You already had to read the README to figure out how to compile it, and check if there was a style guide, and review guidelines for contribution…
Note that your magithub process is the same number of steps but none of them have “so I won’t have to figure it out ever again”, which on the email process actually eliminates two of your steps.
Your magithub workflow looks much more complicated, and you could use keybindings to plug into send-email as well.
You can do this and even more!
I just remembered a good illustration that might explain my stance a bit better. My wife, a garden engineer, was able to contribute to a few projects during Hacktoberfest (three years in a row now), with only a browser and GitHub for Windows at hand. She couldn’t have done it via e-mail, because the only way she can use her email is via her smart phone, or GMail’s web interface. She knows nothing else, and is not interested in learning anything else either, because these perfectly suit her needs. Yet, she was able to discover projects (by looking at what I contributed to, or have starred), search for TODOs or look at existing issues, fork a repo, write some documentation, and submit a PR. She could have done it all from a web browser, but I set up GitHub for Windows for her - in hindsight, I should have let her just use the browser. We’ll do that this year.
She doesn’t know how to use the command-line, has no desire, and no need to learn it. Her email handling is… something that makes me want to scream (no filters, no labels, no folders - one big, unorganized inbox), but it suits her, and as such, she has no desire to change it in any way.
She doesn’t know Emacs, or any IDE for that matter, and has no real need for them, either.
Yet, her contributions were well received, they were useful, and some are still in place today, unchanged. Why? Because GitHub made it easy for newcomers to contribute. They made it so that contributing does not require them to use anything else but GitHub. This is a pretty strong selling point for many people, that using GitHub (and similar solutions) does not affect any other tool or service they use. It’s distinct, and separate.
Not all projects have work for unskilled contributors. Why should we cater to them (who on the whole do <1% of the work) at the expense of the skilled contributors? Particularly the most senior contributors, who in practice do 90% of the work. We don’t build houses with toy hammers so that your grandma can contribute.
I’m not saying we shouldn’t make tools which accomodate everyone. I’m saying we should make tools that accomodate skilled engineers and build simpler tools on top of that. Thus, the skilled engineers are not slowed down and the greener contributors can still get work done. Then, there’s a path for newer users to become more exposed to more powerful tools and more smoothly become senior contributors themselves.
You need to get this point down if you want me to keep entertaining a discussion with you: you can build the same easy-to-use UX and drive it with email.
I was under the impression that git + GitHub are exactly these. Git and git send-email for those who prefer those style, GitHub for those who prefer that. The skilled engineers can use the powerful tools they have, while those with a different skillset can use GitHub. All you need is willingness to work with both.
I’m not questioning you can build something very similar, but as long as e-mail is the only driving power behind it, there will be plenty of people who will turn to some other tool. Because filtering email is something you and I can easily do, but many can’t, or aren’t willing to. Not when there are alternatives that don’t require them to do extra work.
Mind you, I consider myself a skilled engineer, and I mainly use GitHub/GitLab APIs, because I don’t have to filter e-mail, nor parse the info in them, the API serves me data I can use in an easier manner. From an integrator point of view, this is golden. If, say, an Emacs integration starts with “Set up your email so mail with these properties are routed here”, that’s not a good user experience. And no, I don’t want to use my MUA to work with git, because magit is a much better, much more powerful tool for that, and I value my productivity.
I’m pretty sure the whole point would be that the “shiny UI” tool would not expose email to the user at all – so the “plenty of people” wouldn’t leave because they wouldn’t know the difference.
So…. pretty much GitHub/GitLab/Gitea 2.0, but with the added ability to open PRs by email (to cater to that workflow), and a much less reliable foundation?
Sure. What could possibly go wrong.
I might have read the README, or skimmed it. But not to figure out how to compile - most languages have a reasonably standardised way of doing things. If a particular project does not follow that, I will most likely just stop caring unless I really, really need to compile it for one reason or another. For style, I hope they have tooling to enforce it, or at least check it, so I don’t have to read long documents and keep it in my head. I have more important things to store there than things that should be automated.
I would likely read the contributing guidelines, but I won’t memorize it, and I certainly won’t try to remember an e-mail address. I might remember where to find it, but it will still be a manual process. Not a terribly long process, but noticeably longer than not having to do it at all.
Because there’s nothing for me to figure out at all, ever (apart from what repo to clone & fork, but that’s a common step between the two workflows).
How is it more complicated? Clone, work, fork, push, open PR (or clone+fork, work, push+PR), of which all but “work” is heavily assisted. None of it requires me to look anything up, anywhere.
And I do, when I’m dealing with projects that use an e-mail workflow. It’s not about shortcuts, but what can be automated, what the IDE can do instead of requiring me to do it.
You can, if you can extract the address to send patches to automatically. You can build something that does that, but then the automation is tied to that platform, just like the PRs are tied to GitHub/GitLab/whatever.
And again, this is just about sending a patch/opening a PR. There’s so much more PRs provide than that. Some of that, you can do with e-mail. Most of it, you can build on top of e-mail. But once you build something on top of e-mail, you no longer have an e-mail workflow, you have a different platform with which you can interact via e-mail. Think issues, labels for them, reviews (with approvals, rejection, etc - all of which must be discoverable by programs reliably), new commits, rebases and whatnot… yeah, you can build all of this on top of e-mail, and provide a web UI or an API or tools or whatever to present the current state (or any prior state). But then you built a platform which requires special tooling to use to its full potential, and you’re not much better than GitHub. You might build free software, but then there’s GitLab, Gitea, Gogs and a whole lot of others which do many of these things already, and are almost as easy to use as GitHub.
I’ve worked with patches sent via e-mail quite a bit in the past. One can make it work, but it requires a lot of careful thought and setup to make it convenient. I’ll give a few examples!
With GitHub and the like, it is reasonably easy to have an overview of open pull requests, without subscribing to a mailing list, or browsing archives. An open PR list is much easier to glance at and have a rough idea than a mailing list. PRs can have labels to help in figuring out what part of the repo they touch, or what state they are in. They can have CI states attached. At a glance, you get a whole lot of information. With a mailing list, you don’t have that. You can build something on top of e-mail that gives you a similar overview, but then you are not using e-mail only, and will need special tooling to process the information further (eg, to limit open PRs to those that need a review, for example).
With GitHub and the like, you can subscribe to issues and pull requests, and you’ll get notifcations about those and those alone. With a mailing list, you rarely have that option, and must do filtering on your own, and hope that there’s a reasonable convention that allows you to do so reliably.
There’s a whole lot of other things that these tools provide over plain patches over email. Like I said before, most - if not all - of that can be built on top of e-mail, but to achieve the same level of convenience, you will end up with an API that isn’t e-mail. And then you have Yet Another Platform.
Because the work for the send-email approach is: clone, work, git send-email. This is fewer steps and is therefore less complicated. Not to mention that as projects become more decentralized as they move away from GItHub, the registration process doesn’t go away and starts recurring for every new forge or instance of a forge you work with.
Yes, that’s what I’m advocating for.
No, I’m proposing all of this can be done with a very similar UX on the web and be driven by email underneath.
So let’s add that to mailing list software. I explicitly acknoweldge the shortcomings of mail today and posit that we should invest in these areas rather than rebuilding from scratch without an email-based foundation. But none of the problems you bring up are problems that can’t be solved with email. They’re just problems which haven’t been solved with emails. Problems I am solving with emails. Read my article!
So what? Why is this even a little bit of a problem? What the hell?
You can’t subscribe to issues or pull requests, you have to subscribe to both, plus new releases. Mailing lists are more flexible in this respect. There are often separate thing-announce, thing-discuss (or thing-users), and thing-dev mailing lists which you can subscribe to separately depending on what you want to hear about.
No, you won’t. That’s simply not how this works.
Look, we’re just not on the same wavelength here. I’m not going to continue diving into this ditch of meaningless argument. You keep using whatever you’re comfortable with.
I don’t think you can count signing up for GitHub if you’re not counting signing up for email.
If you’re using
hub, it’s justhub pull-request. No context switchingIf you’re counting signing up for email you have to count that for GitHub, too, since they require an email address to sign up with.
Using GitHub requires pushing to different repository and then opening the PR on the GitHub Interface, which is a context change. The git-send-mail would be equivalent to sending the PR.
git-send-email is only one step, akin to opening the PR, no need to push to a remote repository. And from the comfort of your development environment. (Emacs in my case)