This is a great article! My stance is largely the same: there are many ways you can get your contributions to me, and for the most part it’s up to you to pick the one that you’re most comfortable with. My own use of sourcehut is fairly similar to the author’s use of gitweb, mostly just an improved UI so that you can pass around URLs to source code. (But I think the author’s complaints about wasting disk space are quite silly.)
Sending the output of git diff is bad tho; I would not even mention it in the list of options. Not only does the maintainer have to write the commit message, but the change gets mis-attributed to them as well! You don’t want this.
WORST: A series of separate emails generated by git send-email
It’s true that git send-email suuuuucks. The usability is terrible and even people who like it repeatedly make mistakes using it when trying to reply to an existing thread. But the main advantage it has over patches is that all the change is already there in the message itself, so you don’t have to copy anything in. Probably not enough to outweigh its downsides, but worth mentioning.
The most interesting comment I’ve had [about switching to a forge] is that a forge puts all your interactions with contributors out in the open
The author talks about this being an advantage because it forces them to be transparent so they can’t lie to contributors or treat them badly otherwise, but I think the much bigger advantage is that other people can see the discussions and revisit a decision later to understand why one approach was chosen over another.
That’s why I will accept trivial changes in the form of a pastebin link to a .patch file in an IRC channel, but for anything nontrivial, I want it on a mailing list or bug tracker comment thread so we can go back to the discussion later if we need to revisit the decision.
But I’d be more interested in thoughts about how to get the best of both worlds. If there were a system for allowing contributions and their review and discussion to happen in public, using software much more lightweight and easier to run than Gitlab, which allowed contribution without requiring anyone to create and manage yet another account
It’s really weird that they would say this because “send your patches to a mailing list” is A) hitting every one of their requirements and B) already the main way that git is being used regularly outside forges! Is the author not aware of this, or do they have reasons for hating mailing lists that they don’t want to get into?
You would think! But actually most of my complaints about git send-email apply even if you have a nice MUA setup! Because during the patch submission process it completely bypasses your MUA, so you can have a great mail setup, and it just won’t use it; git will go talk directly to your SMTP server.
When you use git send-email, the process for the maintainer or whoever is reviewing the patches is great. It’s the process for the contributor that sucks, and that’s the process that needs to be easy to use, because it will frequently be that person’s first time using it.
It doesn’t have to! As long as your MTA provides a sendmail compatible interface, you can reuse your already configured email setup. In fact, all I have in my gitconfig to make git send-email work is:
No need to configure my damn SMTP again! And this brings in all the other perks of reusing my existing mail setup, such as being able to dispatch them while being offline, and automatically sending them once I go online again. I don’t think any other patch submission process allows this workflow!
And I would go even one step further: If you ask me, the bad fame of git send-email mostly is the fault of popular clients not providing a sendmail-compatible interface for easy integration. Wouldn’t it be nice, if you could just use sendmailcmd = thunderbird --sendmail and Thunderbird would pop up to send the mail with your already configured setup?
Sure some people might still not like the mail workflow in general, but a big part of the bad reputation comes just from the misconception that you need to configure your SMTP settings in your git config.
If you ask me, the bad fame of git send-email mostly is the fault of popular clients not providing a sendmail-compatible interface for easy integration
I’ve never heard of any MUA pretending to be sendmail before; is this a common concept? I agree it would be an improvement for git send-email but you can’t really fault MUAs for not implementing such a weird obscure feature.
I used to run the SMTP servers for cambridge university, so I’m reasonably competent at this email thing. But, fuck me, I never trusted git-send-email, I always used git-format-patch and attached the result to a message in my MUA. But also, I haven’t produced a 20 patch series with 5 rounds of review with an email submission workflow — for which I guess git-send-email is probably OK once it has been set up.
Large mailing lists run in the classical way put someone on the hook for additional (compared to personal email) deliverability issues, which is annoying.
emersion wrote pyonji a while ago which seems to deal with some frustrations with git send-email
Opinionated: you will need to use a feature branch workflow similar to GitHub/GitLab. Other workflows and niche setups are out-of-scope.
Auto-detect mail settings: instead of filling the Git config manually, you just need to enter your e-mail address and password the first time pyonji is invoked. (If you’ve already set up git-send-email, pyonji will pick up your mail settings from there.)
No amnesia: the last version, cover letter, and other settings are saved on-disk. No need to manually pass -v2 when sending a new version. Your cover letter is not lost if the network is flaky.
I think most of the issues the author has are solved, or are in the process of being solved, by Forgejo.
Trust
I host Forgejo myself for personal repos and I’m very happy with it. It’s 100% open source, copy-left even.
Heavyweight [and] a lot more effort than hosting a plain git repository
Forgejo is a single binary written in Go. It’s pretty light on resources, I’m running it on a Raspberry Pi 4. It’s easy to install, but there are a couple setup steps. Creating the git user, setting a handful of config options, setting up the systemd service. It’s not a huge deal, but I do think this can be improved if distributions start picking up Forgejo and packaging it properly.
I use Fedora and they have announced they want to move to Forgejo for all their git hosting needs. I hope this will lead to a package in the official repos, I’d love that.
Account management
You don’t need an account to do any of the things that are possible with a bare repo. You can even do more without an account. For example, you can check all the discussions in issues and pull requests as the author mentions. You only need an account for stuff that’s not possible at all with a bare repo, this functionality is purely additive. All the other workflows like sending a mail with a url to a fork and the name of a branch are still possible with a forge! You are circumventing the workflow the forge is offering you, but there is no law against that.
Also, Forgejo is working on federation, so that might improve even further in the future. But I can’t give Forgejo points for it before it actually exists.
You get a workflow imposed on you
The author corrected themselves here, so kudos to them. Just like with GitLab, you can turn off almost all features of a repository. Forgejo even let’s you disable the code section, which I have done for my “notes” wiki. So, everything about the notes repo is hidden, except the wiki.
In conclusion, I don’t think hosting a bare repo is bad, but I do think you’re missing out if you do that. Forgejo often surprises me with features I didn’t know I wanted. Builtin container registry? Awesome, that in combination with Podman+Quadlet is by far the simplest deployment workflow for custom apps that’s fully open-source and self-hosted I have yet to discover. And I didn’t even know about it when I started hosting Forgejo.
You don’t need an account to do any of the things that are possible with a bare repo.
If you want to have contributions coming from people, they need an account.
If they want to comment in some PR/MR or issue, they need an account.
So if you want any collaboration on the project, they need an account or you need to setup secondary service for discussions without need for an account. Forgejo in current state is nice for solo or cathedral-style projects. Not really for bazaar-style projects.
None of that addresses my point: You can do everything with Forgejo you can do with a bare git repo and there is no requirement to use any of the purely additive features that require an account. If you think Forgejo is unsuitable for bazaar-style collaboration, then so is a bare git repo.
This is technically true, but I’ve never seen a Forgejo-hosted repo (other than my own) where the maintainer was willing to accept patches over email. They probably do exist somewhere, but they are unusual. Almost everyone using Forgejo wants you to also use Forgejo.
Probably not a lot that people universally benefit from. But a lot of situational stuff.
First of all, the person hosting Forgejo is getting a lot more features (presumably one makes an account at least for themselves). You can do your own issue tracking, I like to work that way. It’s basically just a project-scoped todo list for me. You can push your own releases, e.g. I might want to cross-compile for ARM on my x86 machine so I can later download it on my raspberry pi. Or a rendered typst document that you want to share with people by sending them a link. You have your own container registry, which is extremely convenient for self-hosting your custom apps. Plus a bunch of language-specific registries (that’s more relevant for orgs I suppose, who want to have private libraries). You get the wiki in case you like that. As mentioned I basically use a “notes” repo with only the wiki activated as my notes app (not luxurious, but handy). You can also host a Forgejo actions runner if you want to build your own CI/CD.
Other people may benefit depending on how the host uses Forgejo. If the host uses Forgejo like a bare repo, then yeah, the benefit is small. (I would say it’s at least a much nicer UI for browsing code, history, diffs and so on.) If the host makes releases, publishes containers, they could benefit that way. The issue tracker can tell people what the host is planning to work on.
In conclusion, the benefits are situational. You may conclude for yourself that there’s not much for you to benefit from hosting Forgejo and that’s fine.
Thank you for the detailed explanation. I don’t think those things would be of interest to the author (based on this blog post, anyway) but I can see how they would be handy if you didn’t already have your own alternatives.
I plan to start self-hosting again sometime so it’s interesting to learn how different people do it.
Also, Forgejo is working on federation, so that might improve even further in the future. But I can’t give Forgejo points for it before it actually exists.
Yeah, federation would solve some of my pain points with Forgejo, because I’m unwilling to open up account creation on my instance, or to have people ask me to make them accounts. Basically, my Forgejo makes my issue tracker public to read, and I will copy in bug reports or comments from email. I also take contributions by email, the same as if I had a bare git repo and gitweb. I guess I do find it kind of more convenient to manage than gitweb, too.
I’m not sure Forgejo would solve any problems OP has, but it wouldn’t make them worse, either.
Also, Forgejo is working on federation, so that might improve even further in the future. But I can’t give Forgejo points for it before it actually exists.
I have a hard time imagining that federation will provide better UX compared to what a decent desktop app for managing patches via email could provide. The contribution flow, if it’s like mastodon, is going to be confusing. Users will also need to have an account somewhere to contribute, and if they find a PR or issue they want to contribute on a different server (say via a link), they will need to go back to their own instance and find the repository there. I hate that about mastodon, where if someone links me to a profile that I want to follow, I need to go back to my own instance and find that user again. Not to mention all the extra work Forgejo will need to re-implement that was handled by email providers such as handling spam.
Yeah, I have no idea what federation could look like, so I’m cautiously pessimistic.
what a decent desktop app for managing patches via email could provide
PLAESE tell me about any apps you know that make email-based workflows bearable. I’M BEGGING YOU.
I’m using aerc at the moment because most GUI clients seem to hate plain text and bottom posting. The TUI is nice, I got the keybinds configured like Helix… but… it’s still email.
Unfortunately aerc (outside of emacs) is one of the better clients. I just think it’s less effort and the end result would be better end if the focus was a new interface for git and email rather than extending git with activitypub and building an interface for that extension.
On the topic of git send-email being the worst, I’ve been slowly working on an ssh app to replace it for git collaboration. It’s still WIP but you can check it out https://github.com/picosh/git-pr
I always thought that the reason we use forges with those MR/PR workflows are because of communication. In an enterprise environment, it’s much more complex to coordinate changes the patch way (at least I would think so as I never tried).
When people get out of work, they just continue with the same workflow, the same forges can be used for personal projects and work fine for communities too.
When people get out of work, they just continue with the same workflow, the same forges can be used for personal projects and work fine for communities too.
I understand why people do this, but I don’t think it’s a good idea to just blindly keep using the same practices that make sense in a corporate environment elsewhere! I see this all the time, especially with docker, and it seems like often it ends up making things way more complicated than it needs to be, just because people don’t take the time to reconsider whether they are actually gaining anything from the extra complexity.
For example, I run gotosocial on my home server. Since it is a single binary with zero external dependencies, it’s very easy to install and operate “by hand”. (I ran it inside tmux for over a year and it never crashed once.) But a lot of people put it in docker and kubernetes because they just assume that everything needs to work the way it does at google. Then when they go to upgrade it, the DB migrations take a long time, and the health checks fail so kubernetes ends up terminating the process in the middle of a migration, which wedges the whole system; and then you better hope you had backups, because your DB is now corrupt. All completely self-inflicted for no reason!
But a lot of people put it in docker and kubernetes because they just assume that everything needs to work the way it does at google.
I think this is another problem.
Some people also want to “practice”. Companies using kubernetes are everywhere now (its not the only tech but it’s quite omnipresent). So if you want to have a larger option of offers, you want to have some experience with it. Either you can show you have that professional experience or that you don’t have it but you actually built something for yourself and know what you’re talking about.
So for sure people self-inflict themselves the pain, but they learn that this is what’s going to happen at their job if they use kubernetes there. I don’t find it particularly bad. People will learn this way, they will learn that backups are important, that kubernetes is no magic, that you need to scale the tech to the purpose.
But I’d be more interested in thoughts about how to get the best of both worlds. If there were a system for allowing contributions and their review and discussion to happen in public, using software much more lightweight and easier to run than Gitlab, which allowed contribution without requiring anyone to create and manage yet another account, with an extremely configurable form of workflow management (if any), and having a hard separation between the discussion-forum layer and the actual git repository so that a compromise wouldn’t allow injecting malware into the target project, I’d be interested in giving it a look!
(I get particularly annoyed when people demand I move to Github for this reason. “Everyone is on Github, get with the programme! Conform!” I’m actually less likely to do it because you said that. Ugh.)
It’s me!
I can’t compare it to gitlab because I never tried that, but forgejo has been easy to setup and maintain as a self-hosted repo for me and my friends. We really just use it as a way to let people browse the code without having to clone it, though, so we’re not using any features like bug trackers.
This is a great article! My stance is largely the same: there are many ways you can get your contributions to me, and for the most part it’s up to you to pick the one that you’re most comfortable with. My own use of sourcehut is fairly similar to the author’s use of gitweb, mostly just an improved UI so that you can pass around URLs to source code. (But I think the author’s complaints about wasting disk space are quite silly.)
Sending the output of
git diffis bad tho; I would not even mention it in the list of options. Not only does the maintainer have to write the commit message, but the change gets mis-attributed to them as well! You don’t want this.It’s true that
git send-emailsuuuuucks. The usability is terrible and even people who like it repeatedly make mistakes using it when trying to reply to an existing thread. But the main advantage it has over patches is that all the change is already there in the message itself, so you don’t have to copy anything in. Probably not enough to outweigh its downsides, but worth mentioning.The author talks about this being an advantage because it forces them to be transparent so they can’t lie to contributors or treat them badly otherwise, but I think the much bigger advantage is that other people can see the discussions and revisit a decision later to understand why one approach was chosen over another.
That’s why I will accept trivial changes in the form of a pastebin link to a .patch file in an IRC channel, but for anything nontrivial, I want it on a mailing list or bug tracker comment thread so we can go back to the discussion later if we need to revisit the decision.
It’s really weird that they would say this because “send your patches to a mailing list” is A) hitting every one of their requirements and B) already the main way that git is being used regularly outside forges! Is the author not aware of this, or do they have reasons for hating mailing lists that they don’t want to get into?
My own notes for potential contributors: https://git.sr.ht/~technomancy/fennel/tree/HEAD/CONTRIBUTING.md#contributing-changes
One place where I’ve seen it work quite well is the notmuch project but I imagine pretty much everyone involved there has a decent email workflow.
You would think! But actually most of my complaints about
git send-emailapply even if you have a nice MUA setup! Because during the patch submission process it completely bypasses your MUA, so you can have a great mail setup, and it just won’t use it; git will go talk directly to your SMTP server.When you use
git send-email, the process for the maintainer or whoever is reviewing the patches is great. It’s the process for the contributor that sucks, and that’s the process that needs to be easy to use, because it will frequently be that person’s first time using it.It doesn’t have to! As long as your MTA provides a sendmail compatible interface, you can reuse your already configured email setup. In fact, all I have in my gitconfig to make
git send-emailwork is:No need to configure my damn SMTP again! And this brings in all the other perks of reusing my existing mail setup, such as being able to dispatch them while being offline, and automatically sending them once I go online again. I don’t think any other patch submission process allows this workflow!
And I would go even one step further: If you ask me, the bad fame of
git send-emailmostly is the fault of popular clients not providing a sendmail-compatible interface for easy integration. Wouldn’t it be nice, if you could just usesendmailcmd = thunderbird --sendmailand Thunderbird would pop up to send the mail with your already configured setup?Sure some people might still not like the mail workflow in general, but a big part of the bad reputation comes just from the misconception that you need to configure your SMTP settings in your git config.
I’ve never heard of any MUA pretending to be sendmail before; is this a common concept? I agree it would be an improvement for
git send-emailbut you can’t really fault MUAs for not implementing such a weird obscure feature.I used to run the SMTP servers for cambridge university, so I’m reasonably competent at this email thing. But, fuck me, I never trusted git-send-email, I always used git-format-patch and attached the result to a message in my MUA. But also, I haven’t produced a 20 patch series with 5 rounds of review with an email submission workflow — for which I guess git-send-email is probably OK once it has been set up.
Large mailing lists run in the classical way put someone on the hook for additional (compared to personal email) deliverability issues, which is annoying.
Public-inbox only needs incoming SMTP, though.
emersion wrote pyonji a while ago which seems to deal with some frustrations with git send-email
I think most of the issues the author has are solved, or are in the process of being solved, by Forgejo.
I host Forgejo myself for personal repos and I’m very happy with it. It’s 100% open source, copy-left even.
Forgejo is a single binary written in Go. It’s pretty light on resources, I’m running it on a Raspberry Pi 4. It’s easy to install, but there are a couple setup steps. Creating the git user, setting a handful of config options, setting up the systemd service. It’s not a huge deal, but I do think this can be improved if distributions start picking up Forgejo and packaging it properly.
I use Fedora and they have announced they want to move to Forgejo for all their git hosting needs. I hope this will lead to a package in the official repos, I’d love that.
You don’t need an account to do any of the things that are possible with a bare repo. You can even do more without an account. For example, you can check all the discussions in issues and pull requests as the author mentions. You only need an account for stuff that’s not possible at all with a bare repo, this functionality is purely additive. All the other workflows like sending a mail with a url to a fork and the name of a branch are still possible with a forge! You are circumventing the workflow the forge is offering you, but there is no law against that.
Also, Forgejo is working on federation, so that might improve even further in the future. But I can’t give Forgejo points for it before it actually exists.
The author corrected themselves here, so kudos to them. Just like with GitLab, you can turn off almost all features of a repository. Forgejo even let’s you disable the code section, which I have done for my “notes” wiki. So, everything about the notes repo is hidden, except the wiki.
In conclusion, I don’t think hosting a bare repo is bad, but I do think you’re missing out if you do that. Forgejo often surprises me with features I didn’t know I wanted. Builtin container registry? Awesome, that in combination with Podman+Quadlet is by far the simplest deployment workflow for custom apps that’s fully open-source and self-hosted I have yet to discover. And I didn’t even know about it when I started hosting Forgejo.
If you want to have contributions coming from people, they need an account. If they want to comment in some PR/MR or issue, they need an account.
So if you want any collaboration on the project, they need an account or you need to setup secondary service for discussions without need for an account. Forgejo in current state is nice for solo or cathedral-style projects. Not really for bazaar-style projects.
None of that addresses my point: You can do everything with Forgejo you can do with a bare git repo and there is no requirement to use any of the purely additive features that require an account. If you think Forgejo is unsuitable for bazaar-style collaboration, then so is a bare git repo.
This is technically true, but I’ve never seen a Forgejo-hosted repo (other than my own) where the maintainer was willing to accept patches over email. They probably do exist somewhere, but they are unusual. Almost everyone using Forgejo wants you to also use Forgejo.
True. But that’s because they dislike email, not because Forgejo is putting some kind of obstactle in their way to accept patches via email.
What can you do with Forgejo without an account that you can’t do with a bare repo?
Probably not a lot that people universally benefit from. But a lot of situational stuff.
First of all, the person hosting Forgejo is getting a lot more features (presumably one makes an account at least for themselves). You can do your own issue tracking, I like to work that way. It’s basically just a project-scoped todo list for me. You can push your own releases, e.g. I might want to cross-compile for ARM on my x86 machine so I can later download it on my raspberry pi. Or a rendered typst document that you want to share with people by sending them a link. You have your own container registry, which is extremely convenient for self-hosting your custom apps. Plus a bunch of language-specific registries (that’s more relevant for orgs I suppose, who want to have private libraries). You get the wiki in case you like that. As mentioned I basically use a “notes” repo with only the wiki activated as my notes app (not luxurious, but handy). You can also host a Forgejo actions runner if you want to build your own CI/CD.
Other people may benefit depending on how the host uses Forgejo. If the host uses Forgejo like a bare repo, then yeah, the benefit is small. (I would say it’s at least a much nicer UI for browsing code, history, diffs and so on.) If the host makes releases, publishes containers, they could benefit that way. The issue tracker can tell people what the host is planning to work on.
In conclusion, the benefits are situational. You may conclude for yourself that there’s not much for you to benefit from hosting Forgejo and that’s fine.
Thank you for the detailed explanation. I don’t think those things would be of interest to the author (based on this blog post, anyway) but I can see how they would be handy if you didn’t already have your own alternatives.
I plan to start self-hosting again sometime so it’s interesting to learn how different people do it.
Yeah, federation would solve some of my pain points with Forgejo, because I’m unwilling to open up account creation on my instance, or to have people ask me to make them accounts. Basically, my Forgejo makes my issue tracker public to read, and I will copy in bug reports or comments from email. I also take contributions by email, the same as if I had a bare git repo and gitweb. I guess I do find it kind of more convenient to manage than gitweb, too.
I’m not sure Forgejo would solve any problems OP has, but it wouldn’t make them worse, either.
I have a hard time imagining that federation will provide better UX compared to what a decent desktop app for managing patches via email could provide. The contribution flow, if it’s like mastodon, is going to be confusing. Users will also need to have an account somewhere to contribute, and if they find a PR or issue they want to contribute on a different server (say via a link), they will need to go back to their own instance and find the repository there. I hate that about mastodon, where if someone links me to a profile that I want to follow, I need to go back to my own instance and find that user again. Not to mention all the extra work Forgejo will need to re-implement that was handled by email providers such as handling spam.
Yeah, I have no idea what federation could look like, so I’m cautiously pessimistic.
PLAESE tell me about any apps you know that make email-based workflows bearable. I’M BEGGING YOU.
I’m using aerc at the moment because most GUI clients seem to hate plain text and bottom posting. The TUI is nice, I got the keybinds configured like Helix… but… it’s still email.
Unfortunately aerc (outside of emacs) is one of the better clients. I just think it’s less effort and the end result would be better end if the focus was a new interface for git and email rather than extending git with activitypub and building an interface for that extension.
Interesting to note that the Author of the article is the author of PuTTY, something probably everyone on this site has used at least once.
And the best way to generate this is
git request-pull -pOn the topic of git send-email being the worst, I’ve been slowly working on an ssh app to replace it for git collaboration. It’s still WIP but you can check it out https://github.com/picosh/git-pr
I think that my conclusion from this is that email is just a miserable form of communication.
I always thought that the reason we use forges with those MR/PR workflows are because of communication. In an enterprise environment, it’s much more complex to coordinate changes the patch way (at least I would think so as I never tried).
When people get out of work, they just continue with the same workflow, the same forges can be used for personal projects and work fine for communities too.
I understand why people do this, but I don’t think it’s a good idea to just blindly keep using the same practices that make sense in a corporate environment elsewhere! I see this all the time, especially with docker, and it seems like often it ends up making things way more complicated than it needs to be, just because people don’t take the time to reconsider whether they are actually gaining anything from the extra complexity.
For example, I run gotosocial on my home server. Since it is a single binary with zero external dependencies, it’s very easy to install and operate “by hand”. (I ran it inside tmux for over a year and it never crashed once.) But a lot of people put it in docker and kubernetes because they just assume that everything needs to work the way it does at google. Then when they go to upgrade it, the DB migrations take a long time, and the health checks fail so kubernetes ends up terminating the process in the middle of a migration, which wedges the whole system; and then you better hope you had backups, because your DB is now corrupt. All completely self-inflicted for no reason!
I think this is another problem. Some people also want to “practice”. Companies using kubernetes are everywhere now (its not the only tech but it’s quite omnipresent). So if you want to have a larger option of offers, you want to have some experience with it. Either you can show you have that professional experience or that you don’t have it but you actually built something for yourself and know what you’re talking about. So for sure people self-inflict themselves the pain, but they learn that this is what’s going to happen at their job if they use kubernetes there. I don’t find it particularly bad. People will learn this way, they will learn that backups are important, that kubernetes is no magic, that you need to scale the tech to the purpose.
Sourcehut (https://sourcehut.org/) seems really close to what this person wants.
With exception to “easier to run” I think.
It’s me!
I can’t compare it to gitlab because I never tried that, but forgejo has been easy to setup and maintain as a self-hosted repo for me and my friends. We really just use it as a way to let people browse the code without having to clone it, though, so we’re not using any features like bug trackers.
These rules pert much easier to non-Git VCSs as well since you aren’t locked to a specific UI or workflow.