You must log in or register to comment.
This person obviously has their own way of doing things that works for them and that’s great. Some of his views are patently absurd though. This is mostly commenting on his reasons against using a forge and not a comment that he should do something differently.
Trust
100% fair and I think this is the main take-away from the blog post. If you don’t trust something, don’t use it. Full stop, the post could have ended there and been fine. But then it goes on to say:
You get a workflow imposed on you
You mean like forcing people to use email to submit pull requests to your self-hosted git repos? It doesn’t matter what you are doing, if you are working on an open source project you are going to have workflow limitations. This is arguing a fallacy.
In particular, your project automatically gets a bug tracker – and you don’t get a choice about what bug tracker to use, or what it looks like. If you use Gitlab, you’re using the Gitlab bug tracker. The same goes for the pull request / merge request system.
Nothing is forcing you to use these features so just don’t use them. Plenty of teams use 3rd party tools but host their code in a forge site. Having options available to you automatically is not the same thing as being forced to use them. If it was, JIRA wouldn’t exist because everyone would use github/gitlab/whatever’s built-in issue tracking and project management.
The majority of the post comes across as someone who just doesn’t like the forge sites and aside from the trust aspect, then spent a bunch of effort trying to create associations and limitations between things that don’t exist.
Trust is 100% the main reason not to use a forge site and all the other things cited are superfluous and/or very subjective.
I wouldn’t mind doing a self-hosted git repo and only using cli if I didn’t have to also use email to do so.
Seriously the worst part. Email is a technology that should be left in the past. It’s just awful. There’s no good way to do email.
Do you mean sending patches by email? The author for the article also despises them as suggest alternatives for collaboration where you do “pull request” by people giving you a link to their repo and branch name (like literally asking you to try pulling from their git repo), or sending git bundle files which get around a lot of the problems of trying to send patch files around.
Yes. The only way to send patches without something like Github is over email. I don’t mind all the other stuff, but there’s no other way to do PRs than over email, and I hate email. I didn’t see that he gave alternatives. His preferred solution was an email
The formal PR button in a forge is a way to do that with one click, but a short email with all the same information is just as good.
Like, dawg, no it aint
Email isn’t “the only way” to send patches. In fact, he addresses that:
It doesn’t have to be by email, either. Any method of sending this data to the maintainer is fine. For example, I’m on Mastodon – so you could send me a repository URL via Mastodon if you really wanted to (provided you didn’t mind my responses being very short). Or you could send patches via any other communications medium that you and the maintainer are both on, if it lets you attach files to messages.
His preferred method is just sending a URL over email. You can use any communication method if you both already have an account.
I agree that some public discussion place for patches is an absolute necessity.
No idea what that would look like for the blogger though, maybe Lemmy isn’t even that bad? You don’t even need a Lemmy account to interact, he could use Mastodon to respond.
But yeah the overall vibe of the blog is very much luddite and boomer.
Interesting read, I learned some things that git can do and its’s cool to know it’s possible, but I get the sense that „I’m just used to doing it this way” is the author’s main reason. Making most project communication private is a huge sacrifice, and if all projects did things this way then open source development would be far worse off.
I could imagine an „account-less” git forge that uses email verification to create user sessions that then allow conversation and contribution under that email address and name. You’d have to click a magic link in your email every time you wanted to create a session, but they could be long-lived and you don’t have to manage a password.
I agree that having all the commentary in private by default is not ideal for open source. the email verification idea is interesting since it gives you the benefits of not having to create an account.
To me the article was interesting because it points out ways that git “just works” that people might not realize. Like that you can just create a bare repo and upload to that.
