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

Software is made between commits

zed.dev

Post reply on HN
Print view View original

181–190 of 230 posts

Re: Software is made between commits

#181

Post by brainless »

I agree with the core idea. I am building a coding agent for non-engineers on small/local LLMs only.

Commits are great but for an agent that works for the non-engineers (what I am building), commits cannot be represent the chain of thought since that chain has happened before - in English and has lots of debate/discussion with agents.

Zed is focused on engineers. I am focused on everyone else but I came to similar conclusions since my situation is tighter. Software has to be defined by humans, then codified (in development) by agents and then tested by humans. Deployment, rollbacks, etc. also has to come into the scene.

I have been breaking down the conversation into agents playing roles like PO, PM, Architect, etc. Then taking outputs from those into structured inputs for Rust engineer, Typescript engineer and so on. It is all WIP but holding on to this chain of "chats" is key in my opinion. That is where the software is made.

https://github.com/brainless/nocodo

Re: Software is made between commits

#182

Post by thom »

jimbokun wrote: post #135
thom wrote: post #84

A software team’s job is to collaboratively learn an effective model for operating in a domain. They express that model and those learnings in code, tests and associated documentation. So on the one hand I wholeheartedly agree that pull requests and code reviews fatally undermine this process, but immediately recoil that we’re creating yet more secondary processes and artefacts to distract ourselves. This stuff shoul…

Cheap branching for features and experiments, ability to rollback specific commits quickly, reading the commit message for the last time a line of code changed, are all incredibly important and made possible by distributed version control systems. The current state of the code is not sufficient for modern software development.

At least we agree “modern software development” is the root cause.

Re: Software is made between commits

#183

Post by nightpool »

seabass wrote: post #161
Lindby wrote: post #82

All the things in between my commits is a messy soup. Looking there is not useful to anyone. I rewrite my history with git rebase so each commit is small and atomic. The story I create with my commits is what explains why things are as they are, it doesn't matter if it's the true chronological story on how it actually happened. I agree with the author that reviewing pull requests is too late. The problem with pull re…

The way you use commits sounds like how I tend to use stacked PRs at work. Good commit hygiene is hard to enforce at a team level, but for whatever reason at the PR level people are happy to write good descriptions and keep the sets of changes tidy.

This is purely a function of what people expect to be looked at.... if your team started looking at each individual commit step by step, then you'd probably find that people started paying more attention to how their commit hygiene looks.

Re: Software is made between commits

#184

Post by lmm »

Lindby wrote: post #82

All the things in between my commits is a messy soup. Looking there is not useful to anyone. I rewrite my history with git rebase so each commit is small and atomic. The story I create with my commits is what explains why things are as they are, it doesn't matter if it's the true chronological story on how it actually happened. I agree with the author that reviewing pull requests is too late. The problem with pull re…

Why do you want those commits though? In my experience people only look at history a) to see who wrote the code / when it was last changed, which works equally well with any approach, b) to see which feature it was part of, for which you will click through to the PR anyway, or c) to bisect for when a bug was introduced, in which case unedited/unrebased "noise" commits are more useful because you have more guarantee that each commit compiles and the original train of thought is more useful than the fictional history when you're looking for something unintentional.

Re: Software is made between commits

#185

Post by aakresearch »

0xb0565e486 wrote: post #33
tomjakubowski wrote: post #20

I really don't like this. The code I write between commits is my thinking. I think by writing some code out, deleting it, writing again. The code I write that's shipped in commits is written for others to understand, and is a product of that writing for thinking process. I don't want my thoughts to be serialized, version controlled and publicly accessible. https://www.nature.com/articles/s44222-025-00323-4

Aren't you paid to think?

I grant we are - and also to facilitate understanding of one's thinking by other team members. But what I write "between commits" is not any more an evidence of "thinking" or conducive to "understanding" than the NSFW mouse gestures I make or rubbish I am humming to myself.

Re: Software is made between commits

#186

Post by OtherShrezzing »

teach wrote: post #117
OtherShrezzing wrote: post #45

I don’t see the value proposition here. I’ve seen roughly this feature proposed by multiple companies, and absolutely none of the have given a convincing reason for the technology to exist.

It's interesting that your experience/workflow is so much different than mine. This (claims to) solve a real problem that I deal with every day. My company is remote-only, and my coworkers mostly don't live anywhere near me. We see each other a couple of times a day on video chat, but communicate mostly during the day via Slack. We're also, uh, pretty far along the curve in adopting LLM agents to write good code for…

I see the value in being able to discuss features more centrally. I’m not seeing the value in a per-keystroke delta of the software as it’s built though.

It feels like this communications problem could be solved through draft PRs and a decent slack app integration.

Re: Software is made between commits

#187

Post by hinkley »

bmitc wrote: post #173
hinkley wrote: post #167

Earlier quoted context omitted.

> "fixed, added, deleted" I'm saying get rid of those before you invite people to look at the code. Keep the 'code review changes' one because that's comedy gold when the PR changes forced on you by some snowflake actually cause a production outage at 2:00 am.

That's a lot of tedium and commit theater and is what squashing PRs is for.

Honestly, I think if more people actually used git enough that they understood how the git graph worked, we'd have fewer busted graphs. Like CI, you only get better at the tools if you use them more. And people are avoiding using git features and hoping nobody notices when their journeyman standing bites the rest of us on the ass.

We notice, we just reduce your trust level instead of confronting you. I can think of a lot of things that get bitched about over lunches or coffee much more often, but you're still being complained about.

Re: Software is made between commits

#188

Post by hinkley »

jeremyjh wrote: post #127
bmitc wrote: post #123

Earlier quoted context omitted.

> This is why I use rebase before PRs, and despise squash. You are not going to remember why you wrote that code that way 2 years from now and all we'll have to understand bugs and identify Chesterton's Fence situations is the deltas and the commit history. This forces people to work in a very linear fashion that doesn't match how people actually work. A 400 line commit from a squashed PR should be very manageable wh…

Also - at least in GitHub if you squash with the PR merge action in the UI - the original commit history is still available in the ref maintained by the closed PR yet doesn’t clutter your branch or tags namespace.

What are the numbers these days? What percent of projects are running on github versus say Atlassian?

Re: Software is made between commits

#189

Post by InfinityByTen »

jcgrillo wrote: post #79
InfinityByTen wrote: post #67

Earlier quoted context omitted.

One of my professors in undergrad said: the most dangerous mathematicians are the ones that begin the proof with "Consider a case ...". He said that these mathematicians are the ones who don't share anything about how they got the case and they end up projecting this sort of "magician aura". I don't know how accurate that assessment it, but I think it captures something that never sat well with me. In my life, I've n…

OTOH polishing up the presentation can really improve the experience of a first-time reader of the work (e.g. your code reviewers). If the polishing is done with good intent and proficiency you can make something that was very convoluted and difficult to arrive at digestible with far less effort. It also aids your own understanding: "If we can reduce it to the freshman level that means we really understand it" (or si…

Oh, I *love* those kind of people who take the time to _simplify_ and draw meaningful insights from their first draft. They take the time to ensure that they are not just putting out thoughts for the heck of it. They have gone through a learning journey and they are letting you step on it. They might even make the effort to actually articulate their intuition: "it seemed like a good idea to toy with this, because such and such usually have some connection".

Maybe this is the mathematician's lament rejigged. And I have held it for probably 20 years of my life. I try to do things differently when I write, but I have to say there are enough people who find it sub-standard. It's too imprecise or ambiguous or not clear enough for their taste. They aren't wrong. But I'm not done learning and I start building my thoughts as I go along.

Re: Software is made between commits

#190

Post by sheept »

crimsonnoodle58 wrote: post #130
hinkley wrote: post #53

Earlier quoted context omitted.

This is why I use rebase before PRs, and despise squash. You are not going to remember why you wrote that code that way 2 years from now and all we'll have to understand bugs and identify Chesterton's Fence situations is the deltas and the commit history. If you squash them I have 400 lines of code you 'wrote' all at the same time and only have the feature request it was assigned to as context. Thanks for nothing. Th…

We're the opposite. No rebasing your PR. It changes the hashes which we use for ci/cd. Keep it linear, show me the full history, show me where you merged main back into it, and then we force squash on merge. Main then has a nice single commit with a reference to the branch it came from if you wish to see how it developed. Why would we want to litter main with your 100 commits? You own your code, and if you wish to di…

You can just use --first-parent to skip past commits in merged branches. Squash merges complicate stacked PRs.

But I agree on not rebasing PRs. Another benefit to avoiding force merges is that it's easier for reviewers to compare changes since their last review.

Post reply on HN