If I Could Make My Own GitHub
50 points by robalex
50 points by robalex
- My local copy of the repo should be a representation of the entire repo, not just the code. I should be able to approve a PR from the same VCS I use to check in the code. I should be able to go through my issues by looking through local files.
Fossil already does this. When you clone a Fossil repository, you get the bug tracker, wiki, and forum too, all stored in a single SQLite file. fossil ui opens a local web interface over the whole thing. Point 7 is basically Fossil's design philosophy.
That also runs straight into point 5. Fossil ships with a wiki, forum, and chat built in, exactly the “everything tool” the author warns against.
The catch is that Fossil replaces Git instead of improving it. The author seems to want point 7 fixed while staying inside the git ecosystem, hence Jujutsu and Git compatibility. Fossil solves the problem by saying it was never Git's job in the first place.
Worth to mention Fossil’s own comparison with Git, which in this case reminds me of quote from latest FreeBSD Foundation’s video stating that it’s a complete system, not just a kernel with userland bolted on top. Git, same as Linux seems to follow the UNIX philosophy about doing one thing, and doing it well, while it has built-in PR system of sorts based on mails.
It also says:
A forge shouldn't do everything. Issue tracking yes. Kanban board, probably not. Wiki? I doubt it. Everything tools always turn into crap.
To me it sounds like he wants GitHubs “gh” cli tool integrated in git.
I think he's saying more that each of the various parts of a forge are often good vertical slices that have multiple valid approaches. Combining them means that the the best you get is some generic minimum. Splitting them and making interop between various parts allows best of bread slices to work well (solo devs have very different needs to enterprises)
It also says:
A forge shouldn't do everything. Issue tracking yes. Kanban board, probably not. Wiki? I doubt it. Everything tools always turn into crap.
The problem with each "I want X to also do Y and Z, but no, never A and B" opinion is the question of where to draw the line. Everyone tries to draw the line wherever they personally want it and then treats their own opinion as the Single Obvious Truth.
The Github model is completely bottlenecked on the repo owner approving every forward step.
That's not how Linux development works. Linus has his "lieutenants" who aggregate changes for him from dozens of subsystem maintainers, who in turn got patches from hundreds or thousands of contributors.
That's why Linus can merge 12000 commits in a week, while I slog through a handful of PRs where 90% of time is spent on waiting for one or the other party to respond to a comment.
I wish there was a better way on forges to get PRs somehow tentatively merged. Or let other forks to merge, clean up and batch the PRs to reduce load on the bottleneck maintainer.
Github theoretically has forks, and with some git wrangling it kinda could be done, but Github's UI and conventions fight against that. Forks on Github in 99.99% of cases are merely litter left over from submitting a PR. They're more of an implementation detail leaking than an actual feature.
I feel like sourcehut supports the way Linux development works.
At any rate, if I could build my own forge ("github"), it'd look a whole lot like sourcehut with some extra web sugar for people who don't like to work over email.
sourcehut with some extra web sugar for people who don't like to work over email
fyi sourcehut already has some extra web sugar for people who don't like to work over email. In that its web UI has a 'prepare patchset' button that lets you send the email entirely from the web. The flow is not entirely dissimilar to GitHub's PR. You select the commits to send, add a cover letter (PR body) and press send.
It could use some more sugar ej. you still need to create the repo yourself, there is no button to fork. To apply the patch you need to download the submission as an mbox and run git am. But it does support a web flow to send patches.
For collaboration I would prefer something similar Gerrit than sourcehut. But all the other aspects of sourcehut are pretty good.
It could use some more sugar ej. you still need to create the repo yourself, there is no button to fork.
That is absolutely one of the things I had in mind.
I was also thinking some of the diff views could evolve a little, and some better linkage to "todo" would be helpful.
Forking actually is fairly easy as you can push to a non-existent repo and it will accept and create it if it’s under your account. So you just need to clone add the remote url and push and you effective forked all from cli.
I like that workflow very much for just adding a remote. It's actually one of my very favorite things about sr.ht.
For forking specifically, I'd like it a lot if the web UI had some idea of what a repo was forked from (at least when that makes sense) and would appreciate the button that would naturally accompany that kind of tracking.
Is there just a million dollar idea in making Gerrit but not as painful to set up?
Maybe I'm just too scared of prolog, but it feels very close to what this person wants.
Personally... I've tried out the stacked PR flow (which is meant to help other forges get a bit closer to that) and it was unfortunately a bit of a bust. It's way to easy to get wires crossed, and stuff like CI running on every PR just feels outright wasteful.
There's definitely a general idea here that I think Gerrit would allow for: reducing friction on merges for people "knowing what they're doing". Not to completely disable CI for them or things like that, but having more of a post-merge check flow at times. Pairing solves some of that, granted...
It's way to easy to get wires crossed, and stuff like CI running on every PR just feels outright wasteful.
The inefficiency is not inherent to stacking. You could:
If your build system can cache artifacts and test results efficiently, then (2) doesn't even need to be sequential, especially if you're going with persistent CI runners which work in deltas instead of ephemeral ones which restore/save huge caches on every run.
Maybe I'm just too scared of prolog, but it feels very close to what this person wants.
For what it's worth, Gerrit deprecated their use of Prolog in Gerrit 3.6 (May 2022).
Is there just a million dollar idea in making Gerrit but not as painful to set up?
I think the important point in the author's post is it's what he'd do if he was rich. I believe the answer to your question is "no". Is there a possible product like Gerrit but better that people would love? Yes. Would you be able to get them to pay enough to fund building that product? I think not.
That’s sort of my we are trying to do with https://pr.pico.sh
It’s doesn’t even need a git repo, just patches, a namespace, and an ssh key
There are a couple of companies out there offering "alternative/improved GitHub frontends" but most of them feel constrained by having to tie into actual-GitHub (and also last I saw, most of them had pivoted to AI-assisted code review as a product). Going for a cleaner break like described here feels like it would open up a lot of opportunities, and the prevailing winds right now seem to make such an effort more-possible right now than any other time.