Git without a forge

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

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

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.

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.

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

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

A simple 12 step process...

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

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.

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).

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.

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.

[flagged]

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

> 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.

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?

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...)

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?

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.

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.

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.

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

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.

> 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

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.

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

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).

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/