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

131–140 of 230 posts

Re: Software is made between commits

#131

Post by jimbokun »

aeonik wrote: post #99
hinkley wrote: post #95

Earlier quoted context omitted.

Nobody needs to know quite how messy the process of making the sausage is though. There are steps that provide information, even about how the bugs got in there. But not every thought needs to be expressed.

Disagree. This how people best learn from each other. It's also nice to audit your own thought process objectively. It makes one vulnerable though, that's for sure. Psychologically I mean.

Maybe the person reviewing your PR is too busy to also provide therapy for your internal thoughts while writing the code?

Re: Software is made between commits

#132

Post by jimbokun »

mplanchard wrote: post #27

There are so many early-stage startups also competing in this space right now. I’ve been on the interview circuit the past few weeks and talked to at least two. It’s going to be stiff competition for any of these tools to get well-established enough to be successful at a large scale. I can’t help but feel like it is all enabling a level of developer surveillance with which I am deeply uncomfortable, though.

Too many managers have nowhere near enough real work to do or actual business concerns to worry about, if they are spending all their time observing every keystroke of every developer working for them.

Re: Software is made between commits

#133

Post by jchw »

> Software is made between commits

Yes.

> DeltaDB captures every operation in between [each commit]

No.

First of all, that feels intrusive. I would also prefer to not have a screen recorder that is running 24/7 while I work. Yes, I suppose there's nothing wrong with having my mistakes on display, but also, if I'm doing my job, all of the value I produce is captured by the commit, and it just feels significantly less intrusive that way.

Second of all, I use many different tools, and I don't really want to have to have all of them be integrated into some weird DB. What's the point of capturing everything if randomly it has to go "some external process did something"? Yes I do like that Zed can integrate so many things but that doesn't mean I will use everything integrated into Zed. Last I checked if you use Claude Code in Zed via ACP you can't even rewind and edit old messages.

Finally, personally, I think that we've already lost the plot with commits. It's clear to me that most people are just doing some arbitrary unbounded set of changes then running git commit, then the changeset is reviewed as one giant blob, and then those commits get squashed together. It isn't the end of the world, but having nice hand-crafted commits is amazing. If you've ever ran `git blame` on a project that enforces this, you will understand exactly what I am talking about. Doing stuff like DeltaDB is just going to re-enforce and solidify the practice of slopping together commits. Wonder what's going on? Now you can voyeuristically replay it and view the conversation the user had with LLMs...

And that last point is as interesting as it is frustrating. You couldn't convince someone to write documentation for their changes and the motivation behind those changes just because it's good engineering practice that helps your teammates, but everyone will happily explain it to an LLM. Sure that is in large part because it's needed for the LLM to do the work for them, but it is interesting how much work we will do to please the LLMs that we would not have done before. Suddenly a bunch of weird undocumented things are documented. In CLAUDE.md.

Re: Software is made between commits

#134

Post by jimbokun »

whazor wrote: post #23
prodigycorp wrote: post #14

I have an uneasy feeling in my stomach because i know anthropic or openai acquiring zed is inevitable. They have too many good ideas and their software is too good.

Seems like where anthropic or openai want to go, there are no editors anymore. I personally want better read-only code tools, or maybe the return of UML?

Hmm has there been much success just feeding mermaid diagrams to an agent and having it generate code to implement it?

I imagine many people have tried this but I haven’t yet. And mermaid swim lane diagrams are my go to tool for designing system architecture.

Re: Software is made between commits

#135

Post by jimbokun »

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.

Re: Software is made between commits

#136

Post by jimbokun »

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’ve seen Zed promoted as an alternative to Slack or Teams and you describe how that can be true for development where the collaboration revolves around text files.

Which makes more sense I think than describing it as an alternative for Git PRs.

Re: Software is made between commits

#137

Post by jimbokun »

selicos wrote: post #109
dkdbejwi383 wrote: post #21

Earlier quoted context omitted.

What route is that, and why is everyone screaming at them, for someone out of the loop?

It sounds like they ship a fairly minimal and efficient set of tools or text editor. This would be unwanted bloat by those choosing them for those advantages.

Although the collaboration functionality has been there from the beginning.

Re: Software is made between commits

#138

Post by jimbokun »

pjm331 wrote: post #4

so i think the thing that everyone building these git alternatives is missing is a multi-repo story - unless the expectation is that everyone is going to start operating out of monorepos i've settled on all of this context attached to issues in a project management system and referenced from commits it works just fine - its not like your agent cannot read your issue tracker

Maybe there’s a case to be made for a system that combines issue tracking, Slack conversations, PR reviewing, angent harness, and collaborative editing in a single tool. And Zed could make a nice system to build that tool on top of.

Re: Software is made between commits

#139

Post by jimbokun »

overgard wrote: post #107

I'd have to see the implementation in the editor to really know if I'd want it or not, but my initial impression is that I don't think it's something I would use. I've worked on a couple of products with in-editor collaboration built in (not text editors, but, content creation tools). For the most part collaboration just wasn't something users wanted that much. The problem was that the in-editor collaboration was onl…

I guess it would be perfect for pair programming in a remote work environment.

Re: Software is made between commits

#140

Post by skydhash »

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

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…

Squash and merge (if that’s what you’re talking about) is only useful in a pr context. Each PR would actually be a commit if you we using the git-email model. Commits inside such PR are just snapshots.
Post reply on HN