Git without a forge

https://www.chiark.greenend.org.uk/~sgtatham/quasiblog/git-no-forge/

by todsacerdoti • 1 year ago

322 157 1 year ago

chiark.greenend.org.uk

ndegruchy3• 1 year ago

This is what I love about Fossil[1]. You get all of those extra tools (wiki, chat, forums, bug tracker) in the server that is also in the binary that you use to manage the repo.

So, if you want to serve it, just `fossil server file.fossil` or serve a whole directory of them. Or, if you want, you can just `fossil ui` and muck around yourself, locally. The server supports SSH and HTTPS interactions for cloning and pushing.

All by the same people who make SQLite, Pikchr, and more.

[1] https://fossil-scm.org

system33-• 1 year ago

Yup. +1 for fossil. I wanted an issue tracker that wasn’t text files in the repo. Lots of git-based things that were heavier (gitea and friends) or hackier than I wanted. Decided to finally try out fossil and I think it’s really really neat.

Lyngbakr• 1 year ago

In terms of everyday workflow, does Fossil differ radically from git? If so, what's the learning curve like?

yellowapple3• 1 year ago

That's exactly why I've been using Fossil exclusively for new projects, and have been (very slowly) migrating existing ones over as well. It ain't like my FOSS projects get a whole lot of outside contributions anyway (though I've been tinkering a bit with bidirectional Git syncs so that people can submit GitHub PRs / GitLab MRs / generic Git bundles / etc. in those rare cases).

AceJohnny2• 1 year ago

(tongue-in-cheek:) This is what I hate about Fossil, you get all this extra cruft (wiki, chat, forums, bug tracker) that's a worse version than dedicated software for each.

It really depends on what you're optimizing for.

yellowapple3• 1 year ago

Thankfully, there's not much forcing you to use much of it; the "template repo" I use outright disables forum/wiki/chat/bugtracker access to non-admin users (i.e. anyone who hasn't cracked my password), since most of the time when I throw code out into the world I don't really care all that much about supporting it - and in the cases where I do care, I can always re-enable exactly the things I want.

ndegruchy3• 1 year ago

Fair enough. I usually deny permissions to the features I don't care about if I'm pushing it up on the web. It's nice to have them there if I need them, though.

lordgroff• 1 year ago

If Fossil let me rebase, I'd never use git for personal projects again. I love the whole all-in-one approach and it's all so functional. But the (almost extreme) hostility to a rebase workflow makes it a no go for me, and I'm sure many others.

AndrewDucker• 1 year ago

For some context, Simon is the maintainer of PuTTY, as well as various other cool bits of software.

spudlyo2• 1 year ago

He mentions in TFA that he had a bug tracker for PuTTY before git forges were a thing, one might have gotten this from context.

MaxBarraclough2• 1 year ago

This reminds me of Drew DeVault's advocacy for the traditional email-driven git workflow. [0][1] (Drew is the creator of SourceHut, an email-oriented git forge.)

I think his (Simon's) objection to git send-email emails could be addressed with better tooling, or better use of them. It's 'just' a matter of exporting the emails into a single mailbox file, right? (I'm not experienced with git's email-driven features.)

It seems to work smoothly for the Linux kernel folks; clearly it doesn't have to be clunky.

because git format-patch doesn’t mention what commit the patches do apply against, I’m more likely to encounter a conflict in the first place when trying to apply them.

This is what the --base flag is for. [2]

[0] https://git-send-email.io/

[1] https://git-am.io/

[2] https://git-scm.com/docs/git-format-patch#Documentation/git-...

bjackman3• 1 year ago

It doesn't work smoothly for Linux kernel folks. It's a huge pain in the arse to review code. Some subprojects have CI but mostly it's too much work to set it up. You never know if the code that gets merged is truly what got reviewed. Half the time if you wanna test out someone's patches you have to spend 20 minutes trying to figure out what base commit they even apply to. Old fashioned mail clients are huge pain to deal with (and mail servers? Fuck). Raw text with no concept of "review thread resolved" wastes loads of review energy manually tracking what feedback has or hasn't been addressed. Comparing old and new versions of a patchset (equivalent of a pull request) requires manually searching your mailbox for the different versions, manually applying them to your local repo (hopefully you can find the base commit the old version applies to, which by now might not even exist any more if it's an unstable maintainer branch) and then manually running git-range-diff.

As someone who works with an git-send-email workflow every day, I can tell you, it sucks. Email is not a good substrate for development.

If I were Linus I would be pestering the Linux Foundation to set up a bunch of managed Gerrit instances or something.

imiric4• 1 year ago

Don't they have tooling to help with these issues? Surely a project the size of Linux, for which Git was originally created, would arrive at a workflow that is optimal for most contributors. This won't align with everyone's preferences, of course, but I can't imagine someone like Linus not being happy with it.

karel-3d• 1 year ago

The other guy got downvoted, but... isn't there really some tooling to help with this? Some standardized way of actually sending/reviewing the e-mails?

sourcehut has some GUI around it (that I never actually used). I heard that there is some local terminal thing around the e-mail git flow...?

One thing I like - in theory - is how decentralized/federated it all is. E-mail is the original decentralization/federation! But I never had to actually use it.

Ferret74462• 1 year ago

How do you know it's not a personal tooling issue? I have had very smooth email workflows using GNUS, and I imagine many Linux devs have their own scripts and/or customized clients to handle the email flow.

An argument could be made that developers shouldn't have to build their own workflow to do basic development tasks, but given Linus's past statements on C++ developers, I would assume that he would rather not have developers that cannot handle an email workflow working on Linux (that is, this is WAI).

sneak3• 1 year ago

Email, like nntp and gopher, lost to the web.

People won’t use it if it ain’t on the web.

If you force them to use it anyway, very few people will use it.

DdV’s advocacy stems from the fact that he is a lone-wolf dev, building tooling for other lone-wolf devs. The social and collaborative features sucking is a feature, not a bug.

It falls flat on its face for larger projects and communities.

bigstrat20032• 1 year ago

If you force them to use it anyway, very few people will use it.

And that's perfectly fine. Not all things are for all people, and nor should they even try to be.

TylerE• 1 year ago

See, I don't think it has much to do with not being on "the web" and everything to do with federated services actually being a terrible fit for most users most of the time, and not worth the headaches (e.g. spam, netsplits, missing posts...)

specialist• 1 year ago

Noob questions:

PRs are public and email patches are receiver's inbox only, right?

When I'm assessing the merit of any given project, I'd want see if there's a backlog of PRs, right?

Do projects using email-patch workflows set up listservs for receiving patches?

cortesoft2• 1 year ago

I think it is funny to think of the email-driven git workflow as 'traditional' when it had such a short period of time as the standard way of doing things with git.

Git was created in 2005, and Github was created in 2008. So we had 3 years of email-driven git and 17 years of Github style development.

PhilipRoman• 1 year ago

Patches were being mailed long before that, since they work perfectly fine without Git.

IshKebab2• 1 year ago

Sometimes people just can’t work out how to send me patches at all.

Yeah indeed. I have written but not submitted patches to a project (OpenSBI) because it made the submission process super complicated, requiring signing up to a mailing list, learning how to set up git send-email.

I don't see how he can think creating a GitHub account (which almost everyone already has) is a big barrier when he freely admits his process is incomprehensible.

I don't buy the GitHub locks you in either. It's pretty easy to copy issues and releases elsewhere if it really comes to it. Or use Gitlab or Codeberg if you must.

https://docs.codeberg.org/advanced/migrating-repos/

Any of those are far better than random mailing lists, bugzilla, and emailed patch files.

Putty is great but please don't listen to this.

Brian_K_White2• 1 year ago

I submitted at least one patch to putty some time ago and it was such a nothingburger I don't even remember what it took. Somehow it neither baffled nor infuriated nor even annoyed me a little.

All these complaints and critiques sound like so much baby crying over nothing to me.

jeroenhd2• 1 year ago

Same with the account creation on normal git websites. You fill out three fields and click a link in your email, it's no more complex than git send-email.

I'm sure I can figure out the archaic git email system, how hard can it possibly be? Same with the git bundle thing, this is the first time I've read about it but it seems usable. I don't expect anyone I'll ever directly work with to know what the hell a bundle file is but if a project wants their git commits in that format, it shouldn't be that much of a problem. The biggest hurdle will probably be spam filters, but that's an email problem and not necessarily a git problem.

Or course the downside to all this funky command line stuff is that you're applying a filter on the people who will ever contribute code. Plenty of people don't want to figure out the git's many weird command line flows and communication options. Plenty of developers don't care enough to actually learn about git beyond push/pull/rebase/merge. If you're only interested in the turbo nerds who enjoy using the many tricks git has to offer, you'll probably filter out most contributors, but realistically how many contributors does hobby project on a personal git server ever attract in the first place.

devnullbrain• 1 year ago

when he freely admits his process is incomprehensible.

Which one of the 4 preferred processes, not including the maligned git send-email, and infinite other accepted processes?

q0uaur• 1 year ago

Back when i checked out sr.ht, i really liked the idea of git-send-email precisely because it doesn't require making an account for everything. there's a nice tutorial for how to set it up: https://git-send-email.io/#step-1

worked easily enough for me, i could see myself using it for small patches here and there.

I did end up installing forgejo in my homelab after all, but back then it sounded like federation was much closer than it actually was. i did kind of expect that though, federation gets pretty complex quick.

every time i log into forgejo, i do see that juicy "proceed with OpenID" button though, and i've looked into running my own openid provider a few times - sadly not seeing anything that would work for me yet. honestly i can't believe we went from "facebook sign in" to "google sign in" and are now going to "github sign in" without a single open standard that's gotten some adoption.

immibis2• 1 year ago

Pragmatically, how about fediverse sign in? Tweet this nonce to a bot account to log in.

IshKebab2• 1 year ago

there's a nice tutorial for how to set it up

A simple 12 step process...

kazinator• 1 year ago

requiring signing up to a mailing list

A traditionally configured mailing list allows posts from non-subscribers.

All the mailing lists I operate are like this.

If you have good anti-spam-fu, you can get away with it. Plus, it's possible to have posts from non-members be held for moderation, and you can whitelist non-members who write legitimate posts.

Projects which require people to sign up to their mailing lists to participate are erecting a barrier that costs them users; it's a stupid thing to do, and unnecessary.

Whenever I have to interact with some mailing list, I begin by just sending my query to the list address. If it bounces due to nonmembership, I usually move on, unless it's some important matter.

By the way, some modern lists allow posts from non-members but then rewrite the headers in such a way that the nonmember does not receive replies! This happens in more than one way, I think. One of them is Reply-To Munging: the list robot sets the Reply-To: header redirecting replies to be directed to the list address. The Reply-To throws away the content of the original To and Cc fields.

When this happens to me, I usually refrain from further interaction with the list. I check for replies in their archive. If I'm satisfied with what they said, that's the end of it.

etaweb• 1 year ago

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.

With Forgejo (Codeberg) you can toggle features such as pull requests, issues, etc.

You can also configure any external issue tracker or wiki apparently, though I've never tried it, because those included with the forge are good enough for me.

rglullis2• 1 year ago

Forgejo (once federation is implemented) also fixes the main issue of forcing people to have an account at every forge.

ambigious7777• 1 year ago

I do hope that Forgejo Federation is implemented, but it seems to me progress has stalled on it?

kelnos4• 1 year ago

It does solve that problem, but then creates a huge spam problem. Over at gitlab.xfce.org we are constantly fighting new spam accounts that get created daily. We've done all the recommended/paranoid things, like not allowing new accounts to fork or create repos until we manually give them permission (among other things), and we have a script that runs hourly to shut down suspicious accounts. But it's still nuts.

If anyone with an account on any other gitlab instance could automatically do things on our gitlab instance, it would be a nightmare. We'd probably disable federation if gitlab offered it.

adastra222• 1 year ago

The way he prefers patches to him being sent (git repo URL + branch name) is basically what a forge does. Why make it more complicated for your users?

imiric4• 1 year ago

What's complicated about sending an email with the repo URL? The author concedes that just because they don't use a forge, it doesn't mean the contributors shouldn't.

bigstrat20032• 1 year ago

Why should it matter what potential contributors might want the workflow to be, unless his goal is to maximize contributors? There's nothing wrong with prioritizing your own tools desires, as long as you accept that it might limit how many people want to get involved.

adastra222• 1 year ago

What I’m saying is that his own preferred workflow is the same. When you make a pull request, it shoots the maintainer an email with a link to the git branch. Literally the same thing.

throw940402• 1 year ago

》The simplest kind of git bundle – a full bundle – is a whole git repository, wrapped up into a single file.

Git repo can have executable code! Git hooks are shell commands stored in dir ".git/hooks" executed on events such as merge, commit... That is not duplicated by git clone, I am not sure about bundles. But I would be VERY careful to accept something like compressed git repo from anyone!

fiddlerwoaroof• 1 year ago

Bundles only include things that can be in the pack files: the git objects `git clone` would pull.

makapuf• 1 year ago

As you said, git clone wont copy it, and you don't get a zip of a repo, you get a remote that you can clone/ pull from.

Joker_vD3• 1 year ago

Sorry, did you have to use a Wide character? There is a Narrow version of it: ⟫ U+27EB MATHEMATICAL RIGHT DOUBLE ANGLE BRACKET.

cryptonector3• 1 year ago

Does it cause problems on mobile or something?

throw940402• 1 year ago

That was on my android keyboard.

keybored• 1 year ago

git bundle works like git clone so there's nothing to worry about.

You simply don't know what you are talking about.

zem2• 1 year ago

as someone who finds the whole forge interface a massive improvement in git collaboration workflow I was fully prepared to find the author's arguments against a lightweight self hosted forge unconvincing. but the "need to create an account" is an extremely valid drawback, and one I do not have a good answer to.

LadyCailin• 1 year ago

You need to create an email account, and you’ll be doing that through a big email provider, if you want your emails to get delivered anywhere.

zem2• 1 year ago

yes, but people have an email account already. if they could use that to interact with my git forge that would be ideal.

spudlyo2• 1 year ago

Can one be a full fledged netizen sans email account?

npodbielski2• 1 year ago

I am running my own email server for several years and most of the services on the internet are happily integrate with it. The only times I think I had some sort of the problem was small companies with incorrectly configured exchange that was refusing to deliver my messages.

kelnos4• 1 year ago

but the "need to create an account" is an extremely valid drawback, and one I do not have a good answer to.

I never find this to be a big deal. The friction to create a new account is usually pretty low. Type in my email address, let Firefox generate and save a secure password, maybe do email verification, and I'm in. If I'm willing to spend possibly hours crafting a patch to contribute to some software I like, followed by some code-review back-and-forth, the few minutes spent setting up an account is nothing.

aard• 1 year ago

I very much support this sentiment! If we want a decentralized internet, we need to stop relying on large companies to manage everything for us. Git was designed to be a p2p system, but we very quickly centralized it with forges like Github. It is very discouraging. Most of the internet is like this now--managed by a handful of very powerful organizations. There is no end to the problems this will cause.

sneak3• 1 year ago

Gitea is a foss clone of GitHub that is implementing federation features. It’s absolutely excellent.

duskwuff• 1 year ago

One thing which is particularly excellent about Gitea (and its fork, forgejo) is that it's quite lightweight for what it does. It's a single-process Go application with low memory requirements, and it can use a SQLite database (so you don't need a separate database server).

_flux• 1 year ago

Well, there's https://radicle.xyz/ but it doesn't seem too popular—that is, I've never seen a project that is hosted on it.

jeroenhd2• 1 year ago

There are so many private hosting options for forges at this point that I don't buy the Github excuse anymore. Anyone who actually cares about decentralization can set up a Gitea/Gitlab server (or one of their forks) or use one of the many public alternative code forges. It's also quite common for projects to have read-only copies of their code on Github, where people can easily find them, with links to their real upstream in the README.

These days, Git forges left and right are even working on decentralizing things like issues and comments, something Git doesn't track or care about.

People flock to Github because it's free and easy. Very few people care about the peer-to-peer internet and decentralization that Git was built for.

wahern• 1 year ago

People can ‘git clone’ my code, and there’s a web-based browsing interface (the basic gitweb) for looking around without having to clone it at all.

I host my own public Git repositories, but statically--read-only, no HTML views. I don't want to run any specialized server-side code, whether dynamic or preprocessed, as that's a security vector and system administration maintenance headache I don't want to deal with. You can host a Git repository as a set of static files using any web server, without any special configuration. Just clone a bare repo into an existing visible directory. `git update-server-info` generates the necessary index files for `git clone https://...` to work transparently. I add a post-receive hook to my read-write Git repositories that does `cd /path/to/mirror.git && git fetch && git --bare update-server-info` to keep the public repo updated.

In theory something like gitweb could be implemented purely client-side, using JavaScript or WASM to fetch the Git indices and packs on-demand and generate the HTML views. Some day I'd like to give that a try if someone doesn't beat me to it. You could even serve it as index.html from the Git repository directory, so the browser app and the Git clone URL are identical.

johannes1234321• 1 year ago

I haven't looked into mich details of gibt's packing, but for a big repo you probably don't want a client to download it all nor do a huge amount of http range requests for being able to show the summary page. You think that would work well or would this need at least some caching layer?

sneak3• 1 year ago

You could write a static site generator to generate a website from the repo, so you’re still just serving static files.

dgl• 1 year ago

Getting the tree (at the root) is only a few requests (get the refs or HEAD, get the relevant commit, get the tree ID from that). If pack files aren't involved then that's literally 3 requests. Pack files make this more complex, but careful caching and range requests could reduce that to as few as around 5-8 extra requests (doing binary searching via HTTP range requests). I don't think even libgit2 has APIs for range requests on pack files though, so this would need a special library (or patching libgit2...).

There's also various optimizations on the git side like bitmaps[1] and commit-graphs[2]. If this a bare repo on the server side it shouldn't be a problem to make sure it is in a particular format with receive hooks.

That's just displaying a file listing though. Displaying what GitHub displays with the last change of each file is more complex, maybe the commit graph could be used so the client wouldn't have to fetch everything itself.

  [1]: https://git-scm.com/docs/bitmap-format
  [2]: https://git-scm.com/docs/commit-graph

JamesLeonis• 1 year ago

I like this idea quite a bit. It's lightweight and read-only, which makes it far easier to host. I'm in the process of publishing some of my own repositories so I'm going to give this a try.

paulddraper• 1 year ago

I was expecting the justification to be a stodgy get of my lawn rant.

But the author does a very good and reasonable job of explaining it.

It didn't convince me to do the same thing, but I can't help but nod along to the even-handed pros and cons that he lays out.

rlpb2• 1 year ago

Multiple files to herd. When I get an email with five patch attachments, I have five files to copy around instead of one, with long awkward names.

That’s not correct. You can write the email to an mbox file (your MUA lets you do that, right?) and then use `git am` to pull it all into git.

Why I don’t like it: because the patch series is split into multiple emails, they arrive in my inbox in a random order, and then I have to save them one by one to files, and manually sort those files back into the right order by their subject lines.

The patch series arrives threaded, so your MUA should be able to display them in order. Export them to an mbox file, and then use `git am` again.

There might be ways that someone can send you email in this way and for the patches to be broken such that `git am` won’t work, of course. I take no issue with that part of the argument.

LegionMammal9782• 1 year ago

Not everyone has a fancy client-side MUA that gives them trivial access to mbox files. E.g., a typical webmail service will make exporting mboxes into a whole process at best. (And on the sending side, have fun with the lack of git send-email integration. I've spent far more time than I'd like manually patching up References and In-Reply-To headers.)

Of course, the classic response is "get a better MUA you luser", but that just adds even more steps for people who use webmail services for 99.9% of their email needs.

rlpb2• 1 year ago

People can use webmail for regular email, but then connect a “better” MUA for patch handling. I get that this would be more steps, but for those who don’t want to do this, they probably just use GitHub PRs, and that’s fine, they can carry on doing that :-)

I’m just completing the picture by pointing out that for those who choose to use emails to jockey patches around by mutual agreement, including patches in emails really shouldn’t be a problem.

djha-skin• 1 year ago

For those that don't have an MUA, I have made git-receive-mail[1]. It really is very doable these days to do the email workflow, on both ends.

1: https://github.com/djha-skin/git-receive-mail

mauricioc2• 1 year ago

Of course, the classic response is "get a better MUA you luser"

Git is distributed and allows you to work efficiently with poor connectivity, having full history available at any time, which is a big accessibility point for people with limited connectivity (and also helps people working while traveling, for example). If you do have any email client, you get all of this as well, plus arbitrarily powerful, low-latency filtering and searching. I recommend Greg KH's "Patches carved into stone tablets" talk [0].

Despite your "luser" strawman, people advocating for client-side MUAs mean well and have a point. Try replacing "webmail" by "Notepad" and "client-side MUA" by "emacs/vim" to see how your argument sounds. You probably spend a decent amount of time interacting with email, and the investment in setting up a fast, flexible and powerful environment (preferably reusing your text editor for composing messages) for doing so pays for itself soon.

[0] https://www.youtube.com/watch?v=L8OOzaqS37s

layer8• 1 year ago

Yes, this all stands and falls with using a competent email client. There are some hints regarding email clients here, though focused on sending patches: https://github.com/torvalds/linux/blob/master/Documentation/...

agf• 1 year ago

Gotta plug the Portable Puzzle Collection, by the same author as this post: https://www.chiark.greenend.org.uk/~sgtatham/puzzles/

neilv2• 1 year ago

I can't tell you how many waiting rooms, grocery checkout lines, and delayed public transit that his puzzle collection gotten me through. On every handheld and laptop starting with the Symbian-based Nokia E61.

neilv2• 1 year ago

I even included SGT's puzzle collection in a Linux distro that was optimized for small size (but the puzzles were important)! :)

https://www.neilvandyke.org/lildeb/

oneplane• 1 year ago

I wonder if (especially after finishing the bottom part of the article) a mailing list type of interaction, but with Git, is exactly the sort of "in the open" version that is described as a potential improvement.

I'm not sure to what degree that natively allows for integration between Git and an MTA but it would still have most of the desired aspects.

ajross• 1 year ago

The security analysis in this piece is awful. Basically, author uses git because they don't trust "forges", then proceeds to discuss how a direct attack against the repository history is very hard but "not impossible"[1], while failing to recognize that the by-far-most-robust protection against such an attack is to push it to MORE repositories and MORE clones hosted by MORE entities and not keeping it secret on... your own piece of random hardware you probably got from Amazon.

The rest of it is reasonable advice as far as it goes. Learn how to replicate patches between raw repositories as a good practice, as you'll want to be able to do that anyway. Don't lean too hard on the GitHub abstraction of a "Pull Request" as that won't match what kernel people want, etc...

[1] Technically true, but in practice a ridiculous whopper.

haswell• 1 year ago

The author talks about the effort of hosting something more heavyweight like Gitlab. Having recently decided to self-host a Gitea instance, I was happy to find how ridiculously easy it is to get this up and running.

I'm not hosting this on the public Internet, so maybe it's not a fair comparison, but thought it was worth mentioning that there are lighter/easier forge options than Gitlab.

brutal_chaos_• 1 year ago

I do this as well. Act Runner is great, too, if you want CI. It can be finicky, but I'm running it on a Pi4, so not the best setup for that.

bo1024• 1 year ago

Yes, I've found Gitea very easy to self-host as well (I have two instances facing the public internet at the moment).

qudat• 1 year ago

On the topic of git send-email being the worst: I’ve been slowly working on an ssh app that would replace send-email along with some other ideas surrounding collaboration over at: https://github.com/picosh/git-pr

bhasi• 1 year ago

I did not know about git bundle, thank you.

edfletcher_t137• 1 year ago

Also, I might as well come out and say this: one reason I don’t want to use Github is because it’s the most popular place to host your code.

It's the goth subculture of software development! Because it's popular, it must be eschewed.

Geez.

kelnos4• 1 year ago

You conveniently left out the justification for that statement: because the author believes monocultures are bad, and doesn't want to support them. I think that's entirely reasonable, and characterizing it as "goth subculture" is dishonest.

tylersmith• 1 year ago

monocultures are bad, and doesn't want to support them

is just

it's popular, it must be eschewed.

after a chatgpt pass

__MatrixMan__2• 1 year ago

Being popular makes something a high value target. I think it's quite reasonable to have a threat model which avoids such things.

rurban• 1 year ago

With git bug I'm independent on any forge, accounts and workflows there. I sync my bugs from github, but can also sync it to gitlab or codeberg.

Aeolun2• 1 year ago

The only thing I can ever think of while reading these things is: Why?

What could possibly possess you to want to review and apply patches through email? The whole mentality is just utterly foreign to me.

__MatrixMan__2• 1 year ago

He's got a whole "Why" section.

jlarcombe• 1 year ago

the author explains his reasons in considerable detail in the article...

Aeolun2• 1 year ago

Not far enough up that I wasn’t put off reading any further before I got to it.

ackyshake3• 1 year ago

A particular thing I don’t like about git forge websites is the way they make you create an account.

Exactly. I used to have a GitHub account but as soon as it got bought out by Microsoft, I was gone.

I still refuse to create an account, even though there have been bugs I wanted to report or patches I wanted to contribute. Maybe some maintainers still have email addresses on their profile, many don't. Even if they do, I just don't get the motivation to email them.

People like to complain about email a lot, but I enjoy different mailing lists for open source software. You could have discussions with other users of that software or keep track of development by following the "-devel" list. All you needed is something you already had—email. Sadly, they're becoming less popular. Even python moved to discourse which—dun dun dun—requires an account. grumble grumble

I like SourceHut for many reasons—it's the fastest forge I've used, it's FOSS, doesn't try to copy the GitHub UI like every other Git forge these days. But by far the reason I love it is _because_ it doesn't require me creating an account to contribute. I think of it as gitweb, but nicer.

mcherm2• 1 year ago

I am curious -- what is your concern about creating an account? Is it security? Privacy? The need to keep track of it?

immibis2• 1 year ago

My GitHub account is blocked because I refuse to give them my phone number or install their app. They refused a GDPR deletion request too.

ackyshake3• 1 year ago

Security/privacy yeah. I don't do business with Twitter/Facebook for the same reason. In the case of GitHub, if I want to contribute something, I am going to do it volitionally, knowing they will do whatever they want with it.

Creating an account just locks you in, when the alternative exists or existed before. SourceHut proves this is possible. Why not allow non-accounts to contribute?

TiredOfLife• 1 year ago

How are you posting on HN without an account?

cxr4• 1 year ago

Bad comparison. People who are critical of others' complaints about creating and/or logging in to a GitHub account like this aren't going through the trouble of creating a GitHub account in 2025 (as opposed to, say, 2015) and are clearly logging in once and staying logged in.

I encourage you to try an experiment where you pick three or four (or more) times a day to log out of your HN account and only log back in the next time you need to perform some action that requires an account/authorization. Now do the same with GitHub and compare the experience. They've made merely logging in such a massive pain in the ass that somehow goes beyond the anticipated pain around "here's a forced 2FA workflow you didn't ask for but have to run through, anyway". All so you can be generous with your time to someone else's benefit and e.g. leave a signpost comment with answers to a shared problem in some neglected bugtracker, but it's real a kicker when this is interrupting a semi-flow state.

ackyshake3• 1 year ago

It's a good point, I suppose, but it doesn't have to be so black-and-white. There are certain exceptions to this no-account rule of course, like for your bank.

Now, would HN be better without an account? I believe it would, why not? I like lurking (and sometimes commenting) on HN though so I feel like creating an account is valid. Also, HN works fine without JS and has no trackers, which does tend to get me to create an account.

snthpy• 1 year ago

There are radicle.xyz and tangled.sh .

mellosouls• 1 year ago

The author is obviously entitled to whatever workflow he chooses to use, and he isn't proselytizing here, but by choosing to sidestep industry standards he is ultimately just putting obstacles in front of other coders who might like to contribute.

Unless you're really into git and email, it's just tiresome and a time sink having to work all this out.

Fwiw I've used putty in the past and appreciate his efforts, if not his obscurantist tendencies.

DJHenk• 1 year ago

The regular forges have just as many obstacles. You have to register an account, figure out whether the button you need is 'Pull Request' or 'Merge Request', and what the exact flow is.

The only reason things appeared simple in the past is because of GitHub's monopoly. As soon as you want to get rid of that, life gets more complicated. That is just another tradeoff you have to make.

zoobab2• 1 year ago

Like: "You need a mobile phone number and a mobile subscription to receive an SMS to login."

dspillett2• 1 year ago

ultimately just putting obstacles in front of other coders who might like to contribute

Saying it is just that after reading the full text seems rather reductive and unfair.

That is certainly a likely side effect, of course. It may even be a desirable one, avoiding, or at least reducing, several classes of time wasting contributions (like the glut of single typo fixing pull requests that resulted from an ill-conceived contribution based competition a while back), especially for "open source but not open contribution" projects.

Some projects are not wanting to optimise for the number of contributors above other considerations.

windward• 1 year ago

People who can't grok email aren't making useful changes to PuTTY

zoobab2• 1 year ago

"sidestep industry standards"

De-facto standards are not standards.

Standards are properly discussed, and consensus is detected among the participants.

There was never a discussion on making Github an "industry standard".

npodbielski2• 1 year ago

Interesting how author integrated devops side of his software. Main part why I am running whole GitLab suite for my own projects (like a mobile application for my home control) is to have automatic, build, test and deployment process.

I really disliked i.e. pushing new artifacts for fdroid repo. Build can be very long and I do not plan to look at the command line progress for 30 minutes to make sure that it is ready to be pushed to release.

I guess someone can automate this with some cron jobs or bash scripts, file watchers and etc. But moving it to new machine it so much trouble. With GL I can just make a backup and restore it on the other machine. With everything running in docker it is much easier to get the environment running.

Or at least for me.

fitsumbelay• 1 year ago

I've been reminding myself aka procrastinating to self-host my repos for years until reading this post and spent a few minutes realizing just out how easily I could be interacting with my VPS' git service instead of github. obviously there's a long way to go but it's going to be a winning investment in terms of learnings and data ownership

GTonehour• 1 year ago

How do you send your patch to the maintainer? You send the author an email.

I understand the article thinks of occasional contributors outside of the project. For developers of your team (if any), I guess you could grant them SSH access to push, with git hooks enforcing your workflow (prevent direct commits to main, feature-* branches...).

dspillett2• 1 year ago

Sometimes people just can’t work out how to send me patches at all.

This could actually be useful for "open source but not open contribution" situations. It avoids the thing where people seeing that nice easy pull request button as somehow giving them the right to expect their contribution to be accepted.

"If you don't want contributors, why is it on [insert-forge-here] in the first place?" is a question I've seen asked in discussions about such things. Some people get personally insulted when their pull doesn't happen, even though the project states clearly ahead of time that this is how things are. Heck, some seem to be offended in advance that some hypothetical patch they might produce in future would be rejected.

thallian• 1 year ago

This is basically what I do. Gitea instance with closed registration. So far I did get three different people sending me emails with patches/contributions and all the interactions were quite nice. Of course the stuff I am doing is not well known and I do not advertise it anywhere, which is its own moat I'd say.

arichard123• 1 year ago

I ran a ssh server for a while to store git repositories. We had some with secrets in and I didn't want them on github. I needed to provide read only access and read write access for only some of the repos. I ended up with a bash script that configure system users and groups and permissions to do the job. It's here:

https://github.com/artumi-richard/ssh-git-hosting

I stopped using it years ago. It had the additional advantage of no artificial limits (file sizes etc).

chuckadams• 1 year ago

If you can’t find a button on a website to submit a patch, how do you send your patch to the maintainer? You send the author an email.

"Did you just tell me to go fuck myself?"

"I believe I did, Bob."

robertlagrant• 1 year ago

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.

I 100% agree. When people say things like "You have to be on GitHub because that's where the community is" I don't know what to say. Who cares? Is it really that hard to log into (or not) a different Git server? Do we really want to encourage this idea of community anyway, at a scale larger than an individual project?

LuciOfStars• 1 year ago

SourceHut seems to be mostly what they're looking for. :-P

johntitorjr• 1 year ago

A great turnkey forge option is Forgejo in a docker container. I love how light weight this is though.

https://forgejo.org/

It's crazy how many people today think git == github.

Git without a forge

Related Stories