Live data from Hacker News

If I could make my own GitHub

matduggan.com

71–80 of 160 posts

Re: If I could make my own GitHub

#71
post #12

> Well Y Does Some Of That yes but tangled.org really does do most of that! 1. JJ as the VCS: tangled supports stacked PRs using jj change-ids. https://blog.tangled.org/stacking , we use it a lot to build tangled itself: https://tangled.org/tangled.org/core/pulls 2. Raspberry pi as a forge for a long time: also check, the git server shim is super lightweight, its just an XRPC layer over git repositories + an sqlite3…

Surprised to see raspberry pi for hosting data that's supposed to be integral to a workflow. I've been burned too many times by SD card corruption in the past. Do you use NVME drives nowadays, just curious.

Raspi5 has a pci connection for ssd hardware add-ons, I use one and it runs fine with a 2 TB one, I just let it on forever. This has been on for almost a year currently without issues.

Re: If I could make my own GitHub

#72
post #62

I think there's a gap in the market for a much simpler type of git service. All I need is a remote host to which I can push projects for others to see. I don't particularly want pull requests, actions or anything like that. Maybe a way of facilitating "releases" with compiled binary assets (built locally and uploaded). Forks can be handled by people cloning the repository and uploading a new project.

Can't a lot of this be accomplished by disabling features you don't need? I just checked my Forgejo instance and per repository there are options to disable: Code, Projects, Releases, Packages, Actions, Issues, PRs & Wikis.

Yes. But I would like a public service that took care of that for me. So like github but without the bells and whistles.

Part of the reason for not wanting bells and whistles is for the service to have less chance of dying under a heavy load.

Re: If I could make my own GitHub

#73
post #63
post #28

Earlier quoted context omitted.

Hell, I use the (closed-source) app Smart Audiobook Player and I wanted Audiobookshelf integration. I asked Claude, it decompiled the app, added the extra code, recompiled the APK and it works perfectly, syncing my book's progress with the server. Truly magical, it would have taken me months.

That’s super cool. If no post planned, please consider - that’s very “an app is a home cooked meal”, and I love it.

I could write something, but it would be "I told Claude to do this and it did, I'm happy", there isn't really much more detail to write about. What would you like to see?

Re: If I could make my own GitHub

#74
post #62

Earlier quoted context omitted.

Can't a lot of this be accomplished by disabling features you don't need? I just checked my Forgejo instance and per repository there are options to disable: Code, Projects, Releases, Packages, Actions, Issues, PRs & Wikis.

Yes. But I would like a public service that took care of that for me. So like github but without the bells and whistles. Part of the reason for not wanting bells and whistles is for the service to have less chance of dying under a heavy load.

Pretty much what sourcehut is. In addition you get a public mailing list where people can send issues and patch to.

Re: If I could make my own GitHub

#75

Earlier quoted context omitted.

Yes. But I would like a public service that took care of that for me. So like github but without the bells and whistles. Part of the reason for not wanting bells and whistles is for the service to have less chance of dying under a heavy load.

Pretty much what sourcehut is. In addition you get a public mailing list where people can send issues and patch to.

Oh interesting! I've heard of sourcehut of course, but never looked at it. Thanks for the pointer.

Re: If I could make my own GitHub

#76

Earlier quoted context omitted.

> you can just run the tests on the local machine, and you should be running them as part of your workflow. aren't you describing why you'd want a pre-commit for this? you do not have to remember to do so, and new people do not need to learn it.

There are different workflows. I sometimes commit code that does not compile, so that I have a checkpoint. Or because it’s 16:59 and I want to leave the office (and I want to protect the code I wrote from hardware failure). I’d be annoyed if any pre-commit checks took more than 2-3 minutes, and for most projects, that is not enough to build and run any meaningful tests (especially remotely).

There’s a flag for toggling hook when committing. And you can rebase later to clean up the history.

Re: If I could make my own GitHub

#78

I would use RFC2822 as the underlying format to store any kind of message (pull request, review comment, issue etc.), and of course when displaying messages use CommonMark to style them. Any metadata goes into headers, and Message-ID/In-Reply-To/References headers can be used to link them all together. Using this well defined format you can then decide how to best store and transport all the messages, maybe in a git…

So I think part of the attraction with GitHub is the integration of all 4:

1. Code review 2. Source browsing 3. Ticket tracking 4. CI

It does a mediocre job at all 4. But it does a good job of integrating them all together.

So I agree Gerrit is the superior code review model. but without the other 3 pieces you don't have a product. Even when I was at Google and working every day in Gerrit, I was dissatisfied with the poor integration between code search and code review and with CI.

Google3/Critique/Forge/etc -- Google's internal tooling -- did a much better job of tying that all together.

Re: If I could make my own GitHub

#79
post #46
post #9

Stuff happens in the wrong order. You know the PR. Commit 1: 'Feature.' Commit 2: 'fix.' Commit 3: 'fix.' Commit 4: 'actually fix.' Commit 5: 'please.' Commit 6, made at 11:47 PM on a Thursday: 'asdfasdf'. This person has a family. This person has hobbies. This person is, at this moment, crying. You don't want the feedback loop after the commit you want it before. Let me do an enforced pre-commit hook to run the jobs…

Pre-commit hook running remotely on the forge "before they push" sounds like an oxymoron. How does the code get to the forge for feedback? That's a post-push hook!

> Pre-commit hook running remotely on the forge "before they push" sounds like an oxymoron.

I think the implication is that a user doesn't host the CI locally. They are suggesting that there should be? a configuration to call an API to submit the code changes for some part/total CI checking. This is only beneficial for orgs/individuals which somehow rank dev effectiveness based on how messy a branch PR history is and how many times they have submitted code that passes/fails a build. Maybe due to build cost, maybe due to ego.

I understand what they are asking for, but it feels like misusing git or based on some org process rather than normal development flow. I don't understand the point.

Re: If I could make my own GitHub

#80

> PR approval is too boolean. The PR is approved or it's not approved. Real code review, like real life, lives in the middle This is have-your-cake-and-eat-it. PR approval is a permission so is a boolean. Of course it is. Either the code can be merged or it can't. What's being described really here is just something to make you feel slightly better about yourself whilst approving code you hate ("we should revisit thi…

Gerrit has -2...+2. -2: This is a bad idea, don't do that -1: This is a good idea but needs improvement +1: LGTM but I don't have enough knowledge or authority to approve +2: Approved

And Gerrit has multiple review label that can be customized[0].

So you could require `Verified+2` (CI), `Code-Review+2`, and `Design+2`, for example.

[0]: https://gerrit-review.googlesource.com/Documentation/config-...>

Post reply on HN