Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

If I could make my own GitHub

matduggan.com

Post reply on HN
Print view View original

101–110 of 160 posts

Re: If I could make my own GitHub

#101

Post by hnfong »

wccrawford wrote: post #95
ahartmetz wrote: post #58

Earlier quoted context omitted.

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

I was in camp 'boolean', but I think this has convinced me. I always had a problem that there were developers who didn't really understand the code, but would click 'approve' anyhow because they didn't see any problems in the parts they understood. This meant that they were completely unable to actually 'approve' a review, but were only able to reject it. They were juniors, so they'd eventually get to that point, but…

Either the code gets merged or it does not. That's the inherent boolean part.

Given that, what's wrong with simply commenting on the PR to document the concerns, issues, lack of knowledge, etc?

Unless you're using those +/-2 to achieve some sort of goal... but you can also do that with labels, tags, etc. on the PR.

Re: If I could make my own GitHub

#102

Post by rprwhite »

ahartmetz wrote: post #58
dust-jacket wrote: post #47

> 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

This seems like it’s conflating problems. It’s actually two different problems:

1. Is the PR suitable, and therefore should be approved, and

2. Is this person suitable to make that decision.

If 2 is false then the person should remove themselves from the list of reviewers. Then 1 can follow its normal process.

Re: If I could make my own GitHub

#103

Post by mananaysiempre »

onionisafruit wrote: post #94
mananaysiempre wrote: post #45

Earlier quoted context omitted.

There were a few efforts like that back in the day (when people still cared about offline and store-and-forward-style operation[1]), like Bugs Everywhere[3], git-appraise[4] which stored its data in Git’s little-known “notes” namespace[5], and git-bug[6] which for some reason I’ve seen mentioned quite a bit in such threads recently unlike the others—though I’m not complaining about one of them getting mentioned at le…

Well cited. Even your citations have citations.

That was in an annoyed-rant footnote, not a citation footnote :)

Re: If I could make my own GitHub

#105

Post by esafak »

If anybody here does do this -- and please do -- abstract out the VCS backend so we're not stuck with git. Let people bring their own CI/CD too. If you must roll your own CI don't use YAML, for mercy's sake; use a declarative definition (a la bazel with CUE, Skylark) or actual code.

Re: If I could make my own GitHub

#106

Post by unethical_ban »

chii wrote: post #81
ahartmetz wrote: post #58

Earlier quoted context omitted.

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

everything except +2 is unapprove. The nuance is comments on the PR itself, rather than the state of the approval, which is binary (or ternary, if you want to count leaving it in an unknown state for extended periods of time).

To be clear, that is an opinion, not an objective truth.

Some people think that PR status can also communicate rationales and partial approvals.

Some think that should be done with tags and comments.

Lots of request systems have multiple stages between "open" and "resolved".

Re: If I could make my own GitHub

#107

Post by esafak »

rhubarbtree wrote: post #104

Does this conversation exist in 2026? If we can all code everything quickly and SaaS has no value then just build your own in a weekend and put GitHub out of business? There is a fundamental contradiction here.

If you can code it up quickly please do so. I'll sign up. I'm already busy coding other things.

Re: If I could make my own GitHub

#108

Post by eggprices »

Kwpolska wrote: post #15

> 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 jo…

Real problem is the CI can only run through the CI system. If the CI runs "make" the developer can run "make" at home and get feedback. If the CI is GitHub Actions you can only run it by committing and pushing to GitHub.

Re: If I could make my own GitHub

#109

Post by maerF0x0 »

> Stuff happens in the wrong order.

Seems like there are lots of answers: pre-commits, rebase squashes, merge squash...

    git commit --no-verify
    git commit --amend --no-edit
Feedback + commit is a loop. I often reply to comments w/ the commit sha that resolves it.

Re: If I could make my own GitHub

#110

Post by kps »

hnfong wrote: post #101
wccrawford wrote: post #95

Earlier quoted context omitted.

I was in camp 'boolean', but I think this has convinced me. I always had a problem that there were developers who didn't really understand the code, but would click 'approve' anyhow because they didn't see any problems in the parts they understood. This meant that they were completely unable to actually 'approve' a review, but were only able to reject it. They were juniors, so they'd eventually get to that point, but…

Either the code gets merged or it does not. That's the inherent boolean part. Given that, what's wrong with simply commenting on the PR to document the concerns, issues, lack of knowledge, etc? Unless you're using those +/-2 to achieve some sort of goal... but you can also do that with labels, tags, etc. on the PR.

> Either the code gets merged or it does not. That's the inherent boolean part.

In many environments that depends on more than just code review, e.g. CI.

Post reply on HN