Live data from Hacker News

If I could make my own GitHub

matduggan.com

91–100 of 160 posts

Re: If I could make my own GitHub

#91
post #82

> This person has a family. This person has hobbies. This person is, at this moment, crying. Reminded me one benefit of email-based workflow. If I started receiving email, that's usually because I'm in the right mood to doing so. In such mood, I'll be more focused because I expect nothing else to interrupt my work. My problem with notification is that there's a pull towards clearing them as they show up. But there's…

A email is a notification,so how you are in the mood when it will come.can you elaborate clearly

Re: If I could make my own GitHub

#92
post #90
post #73

Earlier quoted context omitted.

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?

I’ve seen a few posts just like that ^_^ It’s mostly your original story of motivation, in brief prose, that does the heavy lifting of a satisfying post, followed by exactly what spec and names of tools you used, mundane as they may feel, your exact prompt(s) (because this is of technical interest in and of itself), and screenshots of excerpts/link to output. Things that stood out to you along the way would also stan…

Huh, sure, I'll write something up today! You can subscribe to https://stavros.io to get an email (there's a form under each article).

Re: If I could make my own GitHub

#93

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

I mean, that’s fair no? If the UX creates an impasse for the user then this leads to friction in the process. There’s more than one way to address it. One is the user overcomes his own internal dilemma, the other is the UX helps him get there. For example, would be cool if there was a way to do a conditional approval with an issue tied to a stacked PR or something similar (just throwing ideas, point is to surface up the friction as a UX take not a protocol or API issue with git)

Re: If I could make my own GitHub

#94

There's a good argument to be made that the data for reviews could be held in git repos just as easily as the source. It can be done incredibly easily simply by having a branch per review with a known prefix (although these will rapidly clog up the default branch namespace), implemented via git namespaces to be distinct from the main namespace, or maybe just a special branch e.g. ".reviews" that just contains commit…

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.

Re: If I could make my own GitHub

#95

> 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

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 by then, everyone would be used to just ignoring their approvals.

This provides that middle ground.

Re: If I could make my own GitHub

#97
post #91
post #82

> This person has a family. This person has hobbies. This person is, at this moment, crying. Reminded me one benefit of email-based workflow. If I started receiving email, that's usually because I'm in the right mood to doing so. In such mood, I'll be more focused because I expect nothing else to interrupt my work. My problem with notification is that there's a pull towards clearing them as they show up. But there's…

A email is a notification,so how you are in the mood when it will come.can you elaborate clearly

Close the email client. No emails, no notifications.

In the mood for dealing with email, open client.

Re: If I could make my own GitHub

#98
> There are a lot of tools that do parts of this. I want someone to take them, put them all together and fit them up.

But just a few inches earlier, the author stated:

> Everything tools always turn into crap.

This seems like a contradiction to me.

Re: If I could make my own GitHub

#99
> If I clone a repo, I want a pretty limited history for that repo when I clone. If I start to go back in time, spin up a worker to go fetch that stuff from the VCS when I need it.

You want blobless clones:

    git clone --filter=blob:none 
Gets history and only fetches blobs on demand. Github has a great article on it https://github.blog/open-source/git/get-up-to-speed-with-par...

Re: If I could make my own GitHub

#100
post #81

Earlier quoted context omitted.

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

What if you want someone to look at a portion of it but they don't know enough to approve the whole thing. They give +1 Someone else knows the other portion well and sees the +1 and decides to +2. In practice this ends the stalemate where partial owners don't feel confident to approve the whole thing

The PR needs to have someone who knows the whole thing.

Having several people review each separate parts but not understanding the others' can cause interaction bugs. If such bugs cannot happen (say, due to modularity, or type safety guarantees etc), then it won't be the case where you need to have a partial approve.

I am not a fan of partial approve. Either you think the code is approvable, or it isn't.

Post reply on HN