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

171–180 of 230 posts

Re: Software is made between commits

#171

Post by commentsaregood »

I spent the entire article thinking

> this is what comments are for

> that is usually unnecessary, but if it were, a comment would fulfill it

> I literally solved this problem with a comment yesterday

> if the AI needs to know that, I'd explicitly ask it to put it in a skill or AGENTS.md. if a human needs it, I'd put it in a comment

> this is overengineering a purpose comments already fulfill

I dont want a second set of commit changes and a freaking schema that tracks me Ctrl+Z and Shift+Ctrl+Z'ing a bunch just to accomplish what comments already do, wtf.

Re: Software is made between commits

#172

Post by commentsaregood »

tengbretson wrote: post #78

This is going to have so many api keys stored in it.

Likewise, what happens if someone does a npm install or slap a venv or some other thing like that, before adding the equivalent of a gitignore for these things? Did you then just flood two times 200 MB worth of changes into the tracker? What if I just simply build in golang to a subfolder early on, is that v0.0.1 stuck there until someone decides to do the second layer of githistory inspection?

Perhaps not. But I'm not going to be the guy training the Team on how not to do it. They have shaky grasp of the full set of standards for PR's as is.

Re: Software is made between commits

#173

Post by bmitc »

hinkley wrote: post #167
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…

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

Re: Software is made between commits

#175

Post by j16sdiz »

That recording capture code, but not intent and thought.

The only alternative to PR review is pair programming - where you can discuss with your peer in real time, discuss the design, asking questions or clarifications.

Without real time communication, those small delta are pure noise.

Re: Software is made between commits

#176

Post by kccqzy »

eddd-ddde wrote: post #145
steveklabnik wrote: post #104

Earlier quoted context omitted.

To be clear, while jj does that, it's entirely local on your machine, and not shared.

The internal version at least is heavily based on a global commit cloud. If you give me your commit ID I can immediately print it on my workspace without you having to upload a formal change request.

That's not a jj feature, but a CitC feature. You can use it on hg workspaces or plain p4 workspaces.

Re: Software is made between commits

#177

Post by alok-g »

This is something I have been looking for.

I agree with a lot of comments here saying that the "conversation that generates the code" is often not meaningful once the code is there. It is however important to me as development history. Commit messages, meanwhile, are not the right places to hold this conversation.

As of now:

1. I save the conversations as "Prompt ###-XX.md" files into a 'completed prompts' folder within the repository and cite "Prompt ###" in the commit message.

2. I explicitly have the coding agent explain the decisions from the conversations in the generated code/artifacts.

Re: Software is made between commits

#178

Post by spaqin »

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…

If you're just a middle man between your coworkers and the LLM, what's the value you're bringing to the team?

Re: Software is made between commits

#179

Post by boomlinde »

So this is is intended to smooth over the poor work, bad commit hygiene and bad commit messages of "agents", presumably not meaning just any agent but LLM-based ones specifically.

I can already see the change. What I need to know is why, not how exactly. It should be clear from a commit message why a change was made. If it's not, that problem should be addressed during review. I shouldn't have to watch a recap of your conversation with a virtual idiot to understand your commit. If the tools you use to generate code can't be coaxed into producing that level of quality, or if you don't understand the output of your generative tools to the extent that you can describe for someone else why they made a particular change, you have a tooling and competency problem.

If further tooling can solve these problems, then I'm all for it, but the idea here seems to be to not solve that problem, but to burden anyone interrogating the history of a repository with also scrolling through chat histories so that virtual idiots can keep shitting out low-quality changes and so that operators can keep accepting those changes as-is without thinking too much about why.

I guess it doesn't help that tools like GitHub don't really care about commit messages. You can't even comment directly on commit messages during review.

Post reply on HN