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

151–160 of 160 posts

Re: If I could make my own GitHub

#151

Post by jftuga »

xmodem wrote: post #123
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…

I just want a button that says "approve and merge these 3 commits now but these two need re-work"

I like to rebase/squash before pushing because it keeps the commit history cleaner. However, I do like your idea so I guess I could also do a squash/merge after approval (which I already do, anyway).

Re: If I could make my own GitHub

#152

Post by jftuga »

tanh wrote: post #56
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…

This exists in Azure DevOps as Approve with Suggestions

I think this is a good idea as it happens anyways even in GitHub.

Re: If I could make my own GitHub

#153

Post by Levitating »

JetSetIlly wrote: post #59

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.

So we're back to cgit?

Re: If I could make my own GitHub

#154

Post by cmrdporcupine »

Aeolun wrote: post #147
cmrdporcupine wrote: post #85

Earlier quoted context omitted.

The number one thing that gerrit does that is important is keep comments tied to the code between commits. By which I mean the discussion doesn't get broken between changes, and it makes it far more trivial to iterate on things in the review without breaking the discussion. And for the reviewer to see what's changed between revisions at the specific comment point they're looking at. And then have a nice clean commit…

How does that work? If the code the comment applies is to is changed, does it expand the range? Or try to relocate it or something? Or it just doesn’t try at all, and it just applies a comment to a certain change/diff section?

It does (hand waving) things to keep the comment in place. It doesn't always get it 100% right, but it's pretty good.

But more importantly, Gerrit has a "Change-Id" it adds to the git commit which is independent of the git hash, so it can track changes independent on the "logical" commit separate from the physical commit.

It also is able because of this to show you what changed for a given commented section between those commits. Allowing you to properly review the changes.

GitHub just acts like a dumbass and throws away comments or threads if the original commit is rewritten. And so forces you into this garbage workflow of endless "commit to address review comments" or "new version" commits, which then have to be either manually rewritten before merge, turned into a (garbage) merge commit, or squashed down into one commit.

Re: If I could make my own GitHub

#155

Post by habinero »

colechristensen wrote: post #145
habinero wrote: post #142

Earlier quoted context omitted.

That's fine as a hobby, but it has massive drawbacks in a professional setting. If you know what you're getting into, sure, but otherwise you're gonna have a bad time. Some of the drawbacks include: 1. The time & effort you spend dicking around making something you could buy is time & effort not spent on your core business 2. Understanding what to build is not trivial. Sure, the tool you built works for your use case…

>That's fine as a hobby, but it has massive drawbacks in a professional setting. Here's the thing: I don't think so in the age of LLMs. >I’ve noticed that people who have never worked with steel have trouble seeing this—that the motorcycle is primarily a mental phenomenon. They associate metal with given shapes—pipes, rods, girders, tools, parts—all of them fixed and inviolable, and think of it as primarily physical.…

This is what I call the "how hard could it be?" fallacy. It gets devs in trouble alllll the time.

> we've all gotten this rigid view that software we work with is fixed and unchangeable and the LLM boom is going to change that by making ALL of the software we use "any shape we want"

What? Literally nobody in software engineering has this view lol. We take open source code and libraries and adapt them all the time. And make new ones.

Your steel analogy is bad, because you're missing what's complicated about both manufacturing and coding.

I've taken welding and shop classes, I could make a motorcycle. Turning a part on a lathe isn't that hard. Bending steel just needs the right tools. So should I build instead of buying, if I want the motorcycle itself and not a hobby project? Haha absolutely not.

I'm not buying from Honda because I think vehicles are immutable and unchanging things, I'm buying from Honda because it'll be quicker, cheaper, safer, and far more reliable than anything I could do. If I want a hobby project, sure, but otherwise it's a bad idea. [0]

Same thing with code and for the same reason.

> The old advice about the time spend writing your tools is tempered by the fact that LLMs make it very very much easier for a focused smart team to build things.

Yeah, you misunderstand the problem lol. Building is the easy part. It was never the gate.

You can't prompt your way out of understanding what to build. It's so much harder than you think it is.

You also can't prompt your way out of the hassle of running a biz critical system, dealing with outages, supporting users, etc.

[0] After taking a welding class, you'll instantly understood why it's a trade. Making consistent, quality welds is not easy.

Re: If I could make my own GitHub

#156

Post by colechristensen »

habinero wrote: post #155
colechristensen wrote: post #145

Earlier quoted context omitted.

>That's fine as a hobby, but it has massive drawbacks in a professional setting. Here's the thing: I don't think so in the age of LLMs. >I’ve noticed that people who have never worked with steel have trouble seeing this—that the motorcycle is primarily a mental phenomenon. They associate metal with given shapes—pipes, rods, girders, tools, parts—all of them fixed and inviolable, and think of it as primarily physical.…

This is what I call the "how hard could it be?" fallacy. It gets devs in trouble alllll the time. > we've all gotten this rigid view that software we work with is fixed and unchangeable and the LLM boom is going to change that by making ALL of the software we use "any shape we want" What? Literally nobody in software engineering has this view lol. We take open source code and libraries and adapt them all the time. An…

>This is what I call the "how hard could it be?" fallacy.

Uh, I'm not guessing what it will be like, I'm doing it. Both reflecting on a better past when organizations did much more of their computing in house and advocating for modern organization use the new tools we have at our disposal to return to building our own tools.

Re: If I could make my own GitHub

#157

Post by zzo38computer »

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…

There is another case, which is that the code is approved but not merged (in which case the maintainer may apply it manually (with changes), and might list the author of the PR as a co-author of the commit that applies those changes).

Re: If I could make my own GitHub

#158

Post by nadermx »

wewewedxfgdf wrote: post #143
wewewedxfgdf wrote: post #4

Earlier quoted context omitted.

gitwheel.com

Ha ha impressively fast action. From unregistered domain to website in hours. I should have registered it myself.

Wasn't me; Would of been minutes not hours, and wouldn't be a coming soon. Would of been live by now, granted not in the best of shape, but live.

Re: If I could make my own GitHub

#159

Post by hbogert »

BinRoo wrote: post #127

Great ideas, though not a huge fan of pre-commit hooks that run full CI locally :) I'd like to add another idea: automatic PR merge contingent on another PR getting merged.

I shouldn't have to roundtrip to a central server to validate if I'm up to par. I'm not saying the tooling is there already, but we've painted ourselves in a corner by tight coupling our ci to a centralized server.

Re: If I could make my own GitHub

#160

Post by stavros »

DANmode wrote: post #90
stavros wrote: 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…

My god this took forever, legit 8 hours to write:

https://www.stavros.io/posts/adding-a-feature-to-a-closed-so...

I did write a small app to do visual writing critique loops, though, because text feedback by Claude was confusing:

https://github.com/skorokithakis/graphe

Post reply on HN