Software is made between commits(zed.dev)
zed.dev
Software is made between commits
https://zed.dev/blog/introducing-deltadb
229 comments
> The problem with pull request is that they make it hard to review individual commits since they are geared towards reviewing the result of an entire branch at once. But the answer is not to share all the noise, it should be to encourage small atomic commits so you can review the early work before the entire feature/fix is complete.
Isn't that just a GitHub problem, as opposed to Phabricator, Gerrit, etc.?
Isn't that just a GitHub problem, as opposed to Phabricator, Gerrit, etc.?
It is, but I think it's hard to explain to folks who have only used the Git/GitHub model – I know, I've been that person not really getting it.
I think what's missed is two things:
- In the Phabricator/Gerrit model you typically end up with changes that are smaller than a PR, but bigger than a commit.
- You lose some history, or track it in a different way. With a PR you might add code to address comments in a new commit on the end, but with Phabricator/Gerrit you don't. If you already aggressively rebase in Git to absorb changes into commits that they make sense to go in, this won't be much of a change, and some systems give you views on the history happening within each change. But if you expect to see everything like that in the Git history, you may not get that, but the workflow changes around it and that's ok.
I think both types of review are in a local maxima, where you lose some things to move to the other type, and it was fear of losing those from my workflow that made me resist the change a bit. When you get there though, you realise it's just not a problem.
I think what's missed is two things:
- In the Phabricator/Gerrit model you typically end up with changes that are smaller than a PR, but bigger than a commit.
- You lose some history, or track it in a different way. With a PR you might add code to address comments in a new commit on the end, but with Phabricator/Gerrit you don't. If you already aggressively rebase in Git to absorb changes into commits that they make sense to go in, this won't be much of a change, and some systems give you views on the history happening within each change. But if you expect to see everything like that in the Git history, you may not get that, but the workflow changes around it and that's ok.
I think both types of review are in a local maxima, where you lose some things to move to the other type, and it was fear of losing those from my workflow that made me resist the change a bit. When you get there though, you realise it's just not a problem.
What I've observed both in the comments here, and in my professional network is that people tend to fall into two distinct camps:
1) Those that use git like a crude autosave who then squash on merge
2) Those that prefer neatly wrapped, fully functional atomic commits
It seems those ideas are in direct opposition to one another with 1) being more common in my experience, perhaps as github naturally supports it better plus the fact that stacked commits can solve some of the problems 2) accounts for... but if I had a choice, 1) definitely makes more sense to me.
1) Those that use git like a crude autosave who then squash on merge
2) Those that prefer neatly wrapped, fully functional atomic commits
It seems those ideas are in direct opposition to one another with 1) being more common in my experience, perhaps as github naturally supports it better plus the fact that stacked commits can solve some of the problems 2) accounts for... but if I had a choice, 1) definitely makes more sense to me.
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.
This is the response I expected to see here.
Reading through the article, I'm reminded of my dismay reading this exact sentiment every time version control is discussed. So many people are so quick to throw away their history so that things look "tidy". It makes no sense, but somehow it fits a certain programmer-brain logic that is surprisingly common.
My style is to commit often. Like dozens of times per day. Commits are the record of what happened, and I want as much of that record to exist as possible. I've been saved so many times by a git bisect that landed pointing at a tiny commit to a single line that looks completely innocuous, yet broke something in a subtle way that only got discovered way later.
That's what source control is for, in my opinion. Finding stuff like that. So many of these things would have been really painful to find if I'd had to sift through every line of a big commit.
So to watch people intentionally balling up an entire PR's worth of commits and squashing them together to throw away the only (in my mind) thing that version control is good for, is truly baffling.
But yeah, there are plenty of people like the parent in that camp, so the author's plan to add even more granularity will be an uphill battle.
Reading through the article, I'm reminded of my dismay reading this exact sentiment every time version control is discussed. So many people are so quick to throw away their history so that things look "tidy". It makes no sense, but somehow it fits a certain programmer-brain logic that is surprisingly common.
My style is to commit often. Like dozens of times per day. Commits are the record of what happened, and I want as much of that record to exist as possible. I've been saved so many times by a git bisect that landed pointing at a tiny commit to a single line that looks completely innocuous, yet broke something in a subtle way that only got discovered way later.
That's what source control is for, in my opinion. Finding stuff like that. So many of these things would have been really painful to find if I'd had to sift through every line of a big commit.
So to watch people intentionally balling up an entire PR's worth of commits and squashing them together to throw away the only (in my mind) thing that version control is good for, is truly baffling.
But yeah, there are plenty of people like the parent in that camp, so the author's plan to add even more granularity will be an uphill battle.
But do these intermediary commits run? I wouldn't mind making smaller commits, but usually wait until the changes result in a bunch of code that compiles and does what it should. It sounds as if you do checkpoints that don't necessarily result in working code or pass tests. Not that that is wrong, but it is a very different philosophy. I usually expect what I check out to compile and sort of work. I can't really pick up somebody else's train of thought midway.
> So many of these things would have been really painful to find if I'd had to sift through every line of a big commit.
> So to watch people intentionally balling up an entire PR's worth of commits and squashing them together to throw away the only (in my mind) thing that version control is good for, is truly baffling.
> But yeah, there are plenty of people like the parent in that camp
I'm confused. The parent doesn't want big commits but rather, as they wrote twice, commits that are small, atomic and without noise. So presumably "fix typo" would be removed during rebase but "rename function" would stay and be separate from "implement logic".
> So to watch people intentionally balling up an entire PR's worth of commits and squashing them together to throw away the only (in my mind) thing that version control is good for, is truly baffling.
> But yeah, there are plenty of people like the parent in that camp
I'm confused. The parent doesn't want big commits but rather, as they wrote twice, commits that are small, atomic and without noise. So presumably "fix typo" would be removed during rebase but "rename function" would stay and be separate from "implement logic".
I guess the difference between the parent and me is that I’ve been around long enough to see my share of “fix typo “ and “remove logging “ commits that accidentally removed the line above or below.
That’s the commit I want to find six months later when the SVG text is blurry because we’re no longer forcing opacity to 1.0 at the end of a transition.
That’s the commit I want to find six months later when the SVG text is blurry because we’re no longer forcing opacity to 1.0 at the end of a transition.
> So many people are so quick to throw away their history so that things look "tidy". It makes no sense, but somehow it fits a certain programmer-brain logic that is surprisingly common.
I want my commits to reflect the evolution of the theory of the program, not a chronological log of my reflection and attempts. In my local branches I snapshot things that only matters to my working process. And before sharing, I make sure that the commits are atomic with a proper description.
When sending a report, do you also send all the post-it, the notebook with your notes, the books with the highlights , your conversation with your colleagues, your web history? I don’t think you do. My local history have commits that reflect my working process which can be messy. Before sharing I tidy them, so that the changes are easily understood.
> entire PR's worth of commits and squashing them together to throw away the only (in my mind) thing that version control is good for, is truly baffling
A PR is supposed to be atomic if you’re using squash and merge. Bundling different changes is the antipattern here, not the squash and merge.
I want my commits to reflect the evolution of the theory of the program, not a chronological log of my reflection and attempts. In my local branches I snapshot things that only matters to my working process. And before sharing, I make sure that the commits are atomic with a proper description.
When sending a report, do you also send all the post-it, the notebook with your notes, the books with the highlights , your conversation with your colleagues, your web history? I don’t think you do. My local history have commits that reflect my working process which can be messy. Before sharing I tidy them, so that the changes are easily understood.
> entire PR's worth of commits and squashing them together to throw away the only (in my mind) thing that version control is good for, is truly baffling
A PR is supposed to be atomic if you’re using squash and merge. Bundling different changes is the antipattern here, not the squash and merge.
Github default squash commit template & merge strategy makes it easy to go from the squash commit to the feature branch. So you get best of both worlds -- clean master and granular history on the branch. Bisect on master tells you which branch broke it, and then bisect on the branch if you want to find the original commit. Same with blame.
IMO squash 4 the win. Github squash defaults work well. Gitlab squash defaults don't.
IMO squash 4 the win. Github squash defaults work well. Gitlab squash defaults don't.
Imagine a feature in git, where when you merge, you get a single new commit on the main branch like you want, where the message could describe the changes in summary, like you want. But also: the commit contains a reference to the source branch so you can easily find it back, break it down, bisect into it, all without having to leave git or rely on data stored at 3d parties. That would be pretty neat! It's like, the best of both worlds, but all inside git!
Well. That's what a merge commit is.
Your approach is nearly identical to creating a merge commit, except the pointer to the second parent (the "original branch") is indirectly recorded via the PR link, instead of directly inside git.
If you create merge commits, then you have your "clean main branch" (via git log --first-parent), as well as the extended history with all the source commits (via git log). And as a bonus, merge commits are supported by every git host, and they work the same in all of them.
I think the whole "squash merge vs merge commit" discussions would be a lot less prevalent if --first-parent would be how git and git hosts displayed commit histories by default. :(
Well. That's what a merge commit is.
Your approach is nearly identical to creating a merge commit, except the pointer to the second parent (the "original branch") is indirectly recorded via the PR link, instead of directly inside git.
If you create merge commits, then you have your "clean main branch" (via git log --first-parent), as well as the extended history with all the source commits (via git log). And as a bonus, merge commits are supported by every git host, and they work the same in all of them.
I think the whole "squash merge vs merge commit" discussions would be a lot less prevalent if --first-parent would be how git and git hosts displayed commit histories by default. :(
That's interesting, so you keep the branches from before the squash -- but do you also rename them somehow, to show that they're now "frozen historic versions"?
Actually, what I usually do in Github is set the PR branches to delete when you squash-merge the PR, but then the PR always has an "undelete branch" button you can use forver in case you want to look at the details of the branch and don't have a local copy of the branch.
Interesting, didn't know about that Github functionality.
I'd like to not depend that much on Github, and instead I'm thinking about having some kind of archival repo where noisy boring historical stuff can be saved (but I'd delete the branches in the main repo). Or renaming historical branches, eg adding an "old/" prefix.
I'd like to not depend that much on Github, and instead I'm thinking about having some kind of archival repo where noisy boring historical stuff can be saved (but I'd delete the branches in the main repo). Or renaming historical branches, eg adding an "old/" prefix.
That’s what I do, and I find this talk about “throwing away” code history baffling. It’s version control. Git branching is cheap.
I make a ton of backup copies. I rearrange the history to how I want before I share it (git history split is great). I keep my nonsense, others see a readable changeset. (Only downside is the occasional housecleaning of old branches, but after a while their usefulness diminishes.)
I make a ton of backup copies. I rearrange the history to how I want before I share it (git history split is great). I keep my nonsense, others see a readable changeset. (Only downside is the occasional housecleaning of old branches, but after a while their usefulness diminishes.)
> But yeah, there are plenty of people like the parent in that camp, so the author's plan to add even more granularity will be an uphill battle.
I find it sad to see it as a battle. Can't we agree on the idea that different people may have different preferences?
"Converting everyone to Linux or vim" would be an uphill battle... if it was worth fighting at all. I don't care what OS or text editor others use, as long as I can use the one that is best for me. If I am happy with commits, I don't want to fight with people who aren't... what would be the point?
I find it sad to see it as a battle. Can't we agree on the idea that different people may have different preferences?
"Converting everyone to Linux or vim" would be an uphill battle... if it was worth fighting at all. I don't care what OS or text editor others use, as long as I can use the one that is best for me. If I am happy with commits, I don't want to fight with people who aren't... what would be the point?
> I've been saved so many times by a git bisect that landed pointing at a tiny commit to a single line that looks completely innocuous, yet broke something in a subtle way that only got discovered way later.
I did git bisect exactly zero times in my life.
I did git bisect exactly zero times in my life.
Regardless if it is a messy soup or not, if disk/cost is not an issue, I would have no problem with anyone (likely agents) looking at what I was doing, and forgive me, but my reasoning™.
Not overly confident in my position, but I believe agents prefer the extra information albeit noise to some.
Not overly confident in my position, but I believe agents prefer the extra information albeit noise to some.
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.
This just sounds to me like "frequent auto-commits" with less trust in git. git can handle frequent auto-commits just fine. If you want to "rollup" frequent auto-commits into "cleaner" top-level commits but also keep all the point-in-time "conversation" of your auto-commits, then `git merge --no-ff` from time to time and use tools like `--first-parent` to focus in on "top-level" commits over "conversation" commits.
The git backend already has a ton of "delta DB optimizations" (in git packs and other tools) and it's really just the git frontend that needs a little massaging (`--first-parent`, primarily) and the vast world of "subway-diagram-first/only" Git UIs that should have more "drill down" `--first-parent` counterparts simply because so many people find the subway diagrams ugly/confusing/distasteful.
The git backend already has a ton of "delta DB optimizations" (in git packs and other tools) and it's really just the git frontend that needs a little massaging (`--first-parent`, primarily) and the vast world of "subway-diagram-first/only" Git UIs that should have more "drill down" `--first-parent` counterparts simply because so many people find the subway diagrams ugly/confusing/distasteful.
This is what what I do. I never see the commits from branches but they are there if I need them. Even git blame can be setup to use --first-parent
git bisect also works great with --first-parent. It will never stop surprising me how many people see the two-dimensional DAG of git as a bug to be avoided rather than a very useful feature (and then spend time reinventing things that git could do natively if they just used the second dimension of the git graph a bit more intentionally).
> 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.
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.
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
I don't want my thoughts to be serialized, version controlled and publicly accessible.
https://www.nature.com/articles/s44222-025-00323-4
This was my problem with JJ as well.
I don't want everything in between to be versioned. I'm not even sure, every intermediary state between a commit is relevant or useful.
but feels like, I'm in the minority.
but feels like, I'm in the minority.
To be clear, while jj does that, it's entirely local on your machine, and not shared.
Even on my local, that level of snapshotting adds unneded complexity that has very little value.
Value is of course subjective, but many of jj’s popular features, like undo, are based on this.
(I actually think it’s tremendously valuable for a number of reasons but it’s fine to simply disagree about that.)
(I actually think it’s tremendously valuable for a number of reasons but it’s fine to simply disagree about that.)
Additional complexity ? jj just increase the frequency of snapshots. it does not fundamentality the complexity of the system
The one thing I do like about git’s staging area is that it’s truly useful for reviewing a bunch of changes (bulk actions or automated tools). Go over the change chunk by chunk and stage what matters (magit makes that extremely quick.
That could be probably done by jj. But the git’s way is already fine for me.
That could be probably done by jj. But the git’s way is already fine for me.
Yes, jj does make this very nice and easy. It’s the same idea as git, except that “the index” is just another anonymous change, not a distinct feature.
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.
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 a feature of jj’s integration with Piper, and is not relevant outside of Google, as neither Piper nor that jj integration is available to anyone else.
That's not a jj feature, but a CitC feature. You can use it on hg workspaces or plain p4 workspaces.
I felt the same for a while after switching to jj. I think using the word "commit" in jj is creating a lot of confusing. The snapshotting is closer to auto-save in your favorite editor. In does not change your ability to version and save your work. It's just a savety net for quick undo
It is called that because it is literally a git commit. jj might change it to “revision”, though, we’ll see.
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.
The worst actor would write a new module and check nothing in until it kinda worked. I think it went along with the fragile ego that had people sneaking around fixing bugs in his code without talking to him about it first. He wrote convoluted code that exhibited Kernighan's law and he was about 10 years too senior to still be doing that shit. He bragged about how 'powerful' his code was as if that was a compliment instead of a harbinger. Many times I found bugs in code from the initial commit. Just... give me something man. Anything. Fuck.
Just because you tried random shit until you found the problem doesn't mean you have to fess up to it. You can tell any story you want that gets us from point A to point B now that you know point B is attainable. You can rearrange the commits the way you would have written it if you knew exactly what needed to be done. Drop 90% of the code you wrote and immediately deleted again, anything that doesn't support that narrative.
In law enforcement you have something called Parallel Construction. You can know a suspect is guilty by knowing facts that are not admissible in court. So you need to rediscover those same facts by the book. Grab his trash on trash day. Interview neighbors. Get enough circumstantial evidence to get a search warrant, then go find that evidence again.
The worst actor would write a new module and check nothing in until it kinda worked. I think it went along with the fragile ego that had people sneaking around fixing bugs in his code without talking to him about it first. He wrote convoluted code that exhibited Kernighan's law and he was about 10 years too senior to still be doing that shit. He bragged about how 'powerful' his code was as if that was a compliment instead of a harbinger. Many times I found bugs in code from the initial commit. Just... give me something man. Anything. Fuck.
Just because you tried random shit until you found the problem doesn't mean you have to fess up to it. You can tell any story you want that gets us from point A to point B now that you know point B is attainable. You can rearrange the commits the way you would have written it if you knew exactly what needed to be done. Drop 90% of the code you wrote and immediately deleted again, anything that doesn't support that narrative.
In law enforcement you have something called Parallel Construction. You can know a suspect is guilty by knowing facts that are not admissible in court. So you need to rediscover those same facts by the book. Grab his trash on trash day. Interview neighbors. Get enough circumstantial evidence to get a search warrant, then go find that evidence again.
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 dig into why you did something in a commit, go look in your branch history.
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 dig into why you did something in a commit, go look in your branch history.
> Main then has a nice single commit with a reference to the branch it came from if you wish to see how it developed.
Yeah sorry that's a toy project. You have 50 people push commits for six years and see if those branches don't 'accidentally' get deleted. We need a different VCS tool to get what you're after there.
Yeah sorry that's a toy project. You have 50 people push commits for six years and see if those branches don't 'accidentally' get deleted. We need a different VCS tool to get what you're after there.
GitHub, Gitea, and Forgejo specifically store all commit hashes for PRs in the `refs/pull/` namespace. The end result is that 50 people pushing commits for six years and deleting all of their branches after squash-and-merge loses no information about how the code evolved.
The main branch remains compact with a linear history without the commit noise. Deleted branches can be restored, commits that otherwise do not exist in the history can be interacted with, and so on.
The main branch remains compact with a linear history without the commit noise. Deleted branches can be restored, commits that otherwise do not exist in the history can be interacted with, and so on.
One of our repos at work (56 contributors) still has all the original branch commits visible on PRs that were squashed and merged in 2018, I've never noticed anything like that being deleted accidentally or otherwise.
[deleted]
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.
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.
Probably coulda used an example that isn't itself a fourth amendment violation that essentially requires perjury to accomplish. Also less euphemistically called evidence laundering. Not really a neutral example.
So are you going to go out and commit a crime because a random person used a crime as an analogy?
I’ve done it over less.
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.
Squash smaller commits?
If it's part of the rebase. If commit 3 in the chain doesn't compile and half the tests fail, that's not very useful for someone trying to figure out how an ancient bug nobody noticed for a year got into the code. If commit 4 fixes it, then 3+4 -> 3.
But if you add a function in commit 2, then realize three hours later than you just need to call another function, I don't need to see the function arrive, get used, half the tests written, the whole thing be deleted, and then a couple commits that do it the easy way and only needs 3 tests added.
That fakeout will be in the code tree forever and each new dev who is trying to grok the code will see that the line of whitespace on line 35 came along with a function that doesn't exist anymore and only really ever did on David's machine.
But if you add a function in commit 2, then realize three hours later than you just need to call another function, I don't need to see the function arrive, get used, half the tests written, the whole thing be deleted, and then a couple commits that do it the easy way and only needs 3 tests added.
That fakeout will be in the code tree forever and each new dev who is trying to grok the code will see that the line of whitespace on line 35 came along with a function that doesn't exist anymore and only really ever did on David's machine.
> 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 when tracing a bug in the main branch, especially if the PR has a good description and review. Having a bunch of "fixed, added, deleted" commits all pushed into main seems like a disaster of noise unless you now force everyone to bundle perfectly reversable actions in every commit.
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 when tracing a bug in the main branch, especially if the PR has a good description and review. Having a bunch of "fixed, added, deleted" commits all pushed into main seems like a disaster of noise unless you now force everyone to bundle perfectly reversable actions in every commit.
> Having a bunch of "fixed, added, deleted" commits all pushed into main seems like a disaster of noise unless
unless you skip non-merge commits when reading the history of main. And personally, I don't remember needing to read main's history more often than probably once a year, and even then mostly out of curiosity.
Also: having a bunch of "ticket resolved" commits all pushed into main seems like a disaster of noise, compared to simple "release 203", "release 204", etc. series of commits that comprise the main. Squash even further! Just as you don't need to track every small development change inside a feature request, you don't need to track every small feature or fix inside a full release. Right? You write a changelog (if you even write them) using those 400 merge-commits, then squash it into a one commit for you release, bang, clean history.
unless you skip non-merge commits when reading the history of main. And personally, I don't remember needing to read main's history more often than probably once a year, and even then mostly out of curiosity.
Also: having a bunch of "ticket resolved" commits all pushed into main seems like a disaster of noise, compared to simple "release 203", "release 204", etc. series of commits that comprise the main. Squash even further! Just as you don't need to track every small development change inside a feature request, you don't need to track every small feature or fix inside a full release. Right? You write a changelog (if you even write them) using those 400 merge-commits, then squash it into a one commit for you release, bang, clean history.
> And personally, I don't remember needing to read main's history more often than probably once a year, and even then mostly out of curiosity.
You're probably delegating that work to someone like me who actually figures out what the systemic problem is that caused the same class of bug to make it to production 5 times in the last 3 years. If you're a lead or a principal and still saying this ^ then you need to expand your skillset.
Bad luck doesn't happen very often. Mostly it's blindspots.
I will confess though that the sort of forensics I do is probably not divisable from the fact that I'm also the designated VCS surgeon on every project I've been on since 1998.
You're probably delegating that work to someone like me who actually figures out what the systemic problem is that caused the same class of bug to make it to production 5 times in the last 3 years. If you're a lead or a principal and still saying this ^ then you need to expand your skillset.
Bad luck doesn't happen very often. Mostly it's blindspots.
I will confess though that the sort of forensics I do is probably not divisable from the fact that I'm also the designated VCS surgeon on every project I've been on since 1998.
> "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.
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.
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.
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.
Fully agree, very icky surveillance vibes. In particular:
> DeltaDB breaks your work into a stream of fine-grained deltas. Where Git captures a snapshot at each commit, DeltaDB captures every operation in between and gives each one a stable identity.
I was curious about giving Zed a try, now that it has an emacs keymap. Not anymore. This is such a horribly invasive feature, I absolutely do not want my colleagues reviewing every single intermediate edit, down to the keystroke, that went into the commits I publish for review.
Before I put a PR up for review, I'll sometimes edit my commit history a little bit in magit to make it more linear and digestible--maybe update descriptions, squash some adjacent commits together, etc. This just throws that whole aspect of the job out the window and says "hey, colleague, hoover up this firehose of deltas and enjoy it".
And what the hell does this even mean?
> What we're really after is simple: the conversation with the agent becomes the only conversation you need to have.
Lmao. No. Wrong.
> DeltaDB breaks your work into a stream of fine-grained deltas. Where Git captures a snapshot at each commit, DeltaDB captures every operation in between and gives each one a stable identity.
I was curious about giving Zed a try, now that it has an emacs keymap. Not anymore. This is such a horribly invasive feature, I absolutely do not want my colleagues reviewing every single intermediate edit, down to the keystroke, that went into the commits I publish for review.
Before I put a PR up for review, I'll sometimes edit my commit history a little bit in magit to make it more linear and digestible--maybe update descriptions, squash some adjacent commits together, etc. This just throws that whole aspect of the job out the window and says "hey, colleague, hoover up this firehose of deltas and enjoy it".
And what the hell does this even mean?
> What we're really after is simple: the conversation with the agent becomes the only conversation you need to have.
Lmao. No. Wrong.
The more I think about it and your comment the more I wish it was local only. It could be useful to analyze your editing habits and interactions with AI but I want that for my own benefit not random coworkers
Yeah I really would not want all my convos synced up like this. I've been working on a personal version of something like this but it keeps all your conversations and notes in a separate Git repo that you control that's totally separate from the project repo - it's entirely designed for personal use:
https://github.com/modulecollective/moe
https://github.com/modulecollective/moe
I would probably only use these data if I had some script I could run in it for analysis, and even then optimizing my AI chats is probably pretty low value.. certainly not enough to justify the cost of analysis, unless there's something that provides actionable insights with almost zero time investment.
Producing code edits itself is such a small fraction of the job I'm really not convinced these are valuable data. Mostly the effort and time goes into reading and understanding code, not producing or transforming it.
Producing code edits itself is such a small fraction of the job I'm really not convinced these are valuable data. Mostly the effort and time goes into reading and understanding code, not producing or transforming it.
This seems like a perfect audit feature to flip back and train a model. Or ensure your human worker is working during business hours.
I think they’re mostly considering AI agents. It’s an interesting idea (that I’ve seen before). Everyone trying to reinvent for AI which is fun!
But I am skeptical because just create a text file and put a reference to the commit.
Also, why not just use Fossil? It already lets you bundle whatever in there since it’s an SQLite database. It has all kinds of things built in that can reference commits.
But I am skeptical because just create a text file and put a reference to the commit.
Also, why not just use Fossil? It already lets you bundle whatever in there since it’s an SQLite database. It has all kinds of things built in that can reference commits.
The collaboration part I’m skeptical of but I get it, as it sounds like a feature made for business consumers
This sounds like it is more aligned with what I have created which is "We need to capture your conversations with AI". If you look at
https://github.com/gitsense/gsc-cli/blob/main/internal/cli/r...
you can see that every file has a code block header with a UUID and the AI that was attributed to it. With the UUID, I can tell exactly how the code came about.
What they are working on will be more useful for AI code provenance. It is only a matter of time before you are expected to show your chats with AI as part of the code review and for performance reviews.
So I don't see human collaboration being the main use case. I see tracking, studying and improving the Human-AI relationship...and seeing if somebody should be promoted or not.
An interesting take I've heard is, we will have a token/impact stat where if you spent a shitload of tokens to produce the same impact as somebody else who spent a lot less, you will be the prime candidate for layoffs and/or less pay. This is why I think AI code provenance will become a serious thing in the future.
https://github.com/gitsense/gsc-cli/blob/main/internal/cli/r...
you can see that every file has a code block header with a UUID and the AI that was attributed to it. With the UUID, I can tell exactly how the code came about.
What they are working on will be more useful for AI code provenance. It is only a matter of time before you are expected to show your chats with AI as part of the code review and for performance reviews.
So I don't see human collaboration being the main use case. I see tracking, studying and improving the Human-AI relationship...and seeing if somebody should be promoted or not.
An interesting take I've heard is, we will have a token/impact stat where if you spent a shitload of tokens to produce the same impact as somebody else who spent a lot less, you will be the prime candidate for layoffs and/or less pay. This is why I think AI code provenance will become a serious thing in the future.
Audit purposes for sure. How was this code/concept generated, what were the prompts/requirements, what thinking did the model complete, can this be replicated or repeated, etc.
A vendor conference I was at a few weeks ago focused heavily on this, for most of their Agentic workflow items. How can you show the AIs work, prove what it did was within guidelines, then audit the process and result.
Like, if your system has an AI backed federated search for documents and you ask it a question about those documents, you need an audit trail of the ask, what documents were referenced, and what was returned to the user.
Then if wrong information was supplied that can be pinned down and explained in case of lawsuit or other need.
A vendor conference I was at a few weeks ago focused heavily on this, for most of their Agentic workflow items. How can you show the AIs work, prove what it did was within guidelines, then audit the process and result.
Like, if your system has an AI backed federated search for documents and you ask it a question about those documents, you need an audit trail of the ask, what documents were referenced, and what was returned to the user.
Then if wrong information was supplied that can be pinned down and explained in case of lawsuit or other need.
FYI your link 404s.
Seems like you copied the ellipsified version, so what we get is https://github.com/gitsense/gsc-cli/blob/main/internal/cli/r
Seems like you copied the ellipsified version, so what we get is https://github.com/gitsense/gsc-cli/blob/main/internal/cli/r
Fixed, thanks!
Yea, commits that go into a PR are generally just a sequence of logs and not necessarily a sequential stream of explicit steps.
Aren't you paid to think?
A woodworker is paid to work with wood. But the finished product is the worked wood, not a detailed summary of how the wood was worked with.
No, you are paid to deliver. Whether you do that by thinking + hand-coding or just vibe-coding, or handing the task description to Cthulhu and waiting for him to materialize the solution on your disk, is immaterial.
Unless of course you also have to explain your thinking and problem-solving process in meetings, which happens quite a lot the more senior you get.
Unless of course you also have to explain your thinking and problem-solving process in meetings, which happens quite a lot the more senior you get.
This cannot be the counterargument to every post that basically says "The employer shouldn't be able to access, collect, serialize, and own every breath I take". It's too unserious.
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.
[deleted]
No I'm paid to write code.
No, you are paid to provide solutions for your customers.
and you can do that without thinking?
Don't be afraid to show your thoughts when asked to. The best developers are those that can express their thoughts clearly at any stage throughout their process. This is one of the skills that shows to me the level of experience a developer has.
I don't want the private API key I temporarily hardcoded in my public history. Nor do I want the drag of worrying about so much as sneezing in the general vicinity of a secret in my editor window, when I already self review before commit.
I don't want the unkind rant about a coworker's design as I attempt to figure out what they were smoking when they made the thing I'm trying to use, needlessly offending them. For starters, once it clicks, it might all make sense, and have turned out to be my mistake. For another, even if a rant is warranted, a pass for "tact", or at least limiting the blame to the blame that is warranted, is proper.
I don't want to drag a coworker through my chain of confusion until I've made an appropriate amount of effort to unconfuse myself first. To do otherwise is likely to bring us both to confusion, possibly in different ways, possibly including confusion about what we're confused about, which is just a mess and dead weight. There's a time and place to explain and teach, and a time and place to expose my own confusion and ask for help, but neither is step 1.
Even if the API is undocumented and confusing, even if you're expected to ask for help as step 1, there's value in a fresh set of eyes getting a feel for exactly how the API is confusing before that, thus informing directions for potential improvement (be that API changes or improved documentation.)
I don't want the unkind rant about a coworker's design as I attempt to figure out what they were smoking when they made the thing I'm trying to use, needlessly offending them. For starters, once it clicks, it might all make sense, and have turned out to be my mistake. For another, even if a rant is warranted, a pass for "tact", or at least limiting the blame to the blame that is warranted, is proper.
I don't want to drag a coworker through my chain of confusion until I've made an appropriate amount of effort to unconfuse myself first. To do otherwise is likely to bring us both to confusion, possibly in different ways, possibly including confusion about what we're confused about, which is just a mess and dead weight. There's a time and place to explain and teach, and a time and place to expose my own confusion and ask for help, but neither is step 1.
Even if the API is undocumented and confusing, even if you're expected to ask for help as step 1, there's value in a fresh set of eyes getting a feel for exactly how the API is confusing before that, thus informing directions for potential improvement (be that API changes or improved documentation.)
I'm not advocating committing secrets to version control.
But you can learn to phrase your WTFs about your colleague's code politely and constructively. I would even argue that this an absolutely basic skill for professionals. It typically leads to faster and better answers whenever a discussion arises.
Even if confusion seems to spread in a discussion, I would expect the person who realizes this first to call that out and and to reset the conversation.
There is nothing magic or onerous about this.
But you can learn to phrase your WTFs about your colleague's code politely and constructively. I would even argue that this an absolutely basic skill for professionals. It typically leads to faster and better answers whenever a discussion arises.
Even if confusion seems to spread in a discussion, I would expect the person who realizes this first to call that out and and to reset the conversation.
There is nothing magic or onerous about this.
> But you can learn to phrase your WTFs about your colleague's code politely and constructively.
I see a fundamental difference between thoughts and whatever words I pronounce. You're saying "you should share your thoughts", and I disagree. My thoughts are mine. Whenever I want to share something with the world, I phrase it and share the result of that process.
I see a fundamental difference between thoughts and whatever words I pronounce. You're saying "you should share your thoughts", and I disagree. My thoughts are mine. Whenever I want to share something with the world, I phrase it and share the result of that process.
> But you can learn to phrase your WTFs about your colleague's code politely and constructively. I would even argue that this an absolutely basic skill for professionals. It typically leads to faster and better answers whenever a discussion arises.
Phrasing things politely and constructively is what I'm explicitly advocating for when I'm calling for "tact", yes. But said phrasing is not necessairly the very first thoughts out of my mind. When we push back on sharing our raw thoughts, it's precisely because we want a moment to be able to translate from passionate, driven, and perhaps rude thoughts - to polite, if perhaps a bit professionally dispassionate words. From unconvincing incendiary moral judgements against the cult of the singleton, to concrete examples of maintainence concerns and tradeoffs that can be discussed by everyone. From things that barely make sense in the context of our own minds, to things communicated clearly within the context and bounds of our shared understanding.
> Even if confusion seems to spread in a discussion, I would expect the person who realizes this first to call that out and and to reset the conversation.
Simply calling out confusion is insufficient to resolve confusion. Being able to narrow down what I'm confused about is an important skill and first step towards either unconfusing myself, or seeking help from others, allowing them to aid me in solving said confusion.
Unconfusing others is a step more difficult. Unlike with my own confusion, I find it necessary to build an accurate mental model of their thought process through my own indirect observation and questions, to understand where they've misunderstood, the correct understanding, and then a means of explaining and contrasting those two states through nothing more than clear communication to bring them out of said confusion. I may have to construct full blown examples, showing a concrete way their own initial biases fail them.
These are important skills and steps to take, of course, and you're right that there's nothing magic about it, but this is something I've expended a lot of time on over the decades I've been puttering around in development circles. It's time intensive, requiring one or more people focusing on a single individual's issues, just to reset things to a baseline of being unconfused enough to do good work.
And, of course, it will always be necessary, and I'm glad to help. It's a skill I believe I'm good at, and by unblocking coworkers and friends, I can potentially spend minutes of my time to save hours or even days of theirs, which is well worth it. But it's also worth taking the time to avoid such scenarios coming up again. It saves me time, and it saves them time.
Sometimes that means clearing up ambiguous or confusing documentation.
Sometimes that means keeping others at arm's length - at least until I'm at least no longer confused about what exactly I'm confused about.
Phrasing things politely and constructively is what I'm explicitly advocating for when I'm calling for "tact", yes. But said phrasing is not necessairly the very first thoughts out of my mind. When we push back on sharing our raw thoughts, it's precisely because we want a moment to be able to translate from passionate, driven, and perhaps rude thoughts - to polite, if perhaps a bit professionally dispassionate words. From unconvincing incendiary moral judgements against the cult of the singleton, to concrete examples of maintainence concerns and tradeoffs that can be discussed by everyone. From things that barely make sense in the context of our own minds, to things communicated clearly within the context and bounds of our shared understanding.
> Even if confusion seems to spread in a discussion, I would expect the person who realizes this first to call that out and and to reset the conversation.
Simply calling out confusion is insufficient to resolve confusion. Being able to narrow down what I'm confused about is an important skill and first step towards either unconfusing myself, or seeking help from others, allowing them to aid me in solving said confusion.
Unconfusing others is a step more difficult. Unlike with my own confusion, I find it necessary to build an accurate mental model of their thought process through my own indirect observation and questions, to understand where they've misunderstood, the correct understanding, and then a means of explaining and contrasting those two states through nothing more than clear communication to bring them out of said confusion. I may have to construct full blown examples, showing a concrete way their own initial biases fail them.
These are important skills and steps to take, of course, and you're right that there's nothing magic about it, but this is something I've expended a lot of time on over the decades I've been puttering around in development circles. It's time intensive, requiring one or more people focusing on a single individual's issues, just to reset things to a baseline of being unconfused enough to do good work.
And, of course, it will always be necessary, and I'm glad to help. It's a skill I believe I'm good at, and by unblocking coworkers and friends, I can potentially spend minutes of my time to save hours or even days of theirs, which is well worth it. But it's also worth taking the time to avoid such scenarios coming up again. It saves me time, and it saves them time.
Sometimes that means clearing up ambiguous or confusing documentation.
Sometimes that means keeping others at arm's length - at least until I'm at least no longer confused about what exactly I'm confused about.
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 never liked people who deliberately polish up their articulation to the level that it obfuscates how they arrived at that understanding (whether it's academics or engineers). They might not do it for attention and they might not be doing it knowingly. IMO, they are taking away the opportunity of learning from the people they are talking to. For me the conversation is one sided. I'm there to listen, but rarely can I ask questions, give feedback or grow from where they have possibly reached.
In my life, I've never liked people who deliberately polish up their articulation to the level that it obfuscates how they arrived at that understanding (whether it's academics or engineers). They might not do it for attention and they might not be doing it knowingly. IMO, they are taking away the opportunity of learning from the people they are talking to. For me the conversation is one sided. I'm there to listen, but rarely can I ask questions, give feedback or grow from where they have possibly reached.
Ugh, let's take a step back and make a distinction:
I don't need your fluff. No one cares how you arrived writing another crud line to save an object to database or sent yet another AJAX call.
If you wrote some genuine great compression algorithm that's a different take on compression, I would like to see step by step reasoning and eventual dead ends.
I don't need your fluff. No one cares how you arrived writing another crud line to save an object to database or sent yet another AJAX call.
If you wrote some genuine great compression algorithm that's a different take on compression, I would like to see step by step reasoning and eventual dead ends.
I shared my thoughts in the context of someone saying that one should be able to share your line of thinking when asked to. Whether "when one asked to" applies to keystroke by keystroke blockhained versioning isn't my point of discussion.
I get it, that the overall discussion is about DeltaDB. I'd say interesting concept to toy with. I'd pay more attention to "micro commits" as the idea more than the keylogger.
I get it, that the overall discussion is about DeltaDB. I'd say interesting concept to toy with. I'd pay more attention to "micro commits" as the idea more than the keylogger.
I think a good argument ad absurdum for this is to look at how some recipe sites give the entire genealogical history of the author and an anecdote about how their gammy met Theodore Roosevelt and he stole her pen. Three pages later I discover I need to go to the grocery store because the recipe requires sour cream. And the store is closed so I need a different recipe.
Don't fucking do that. Do something way less than halfway to that line.
Don't fucking do that. Do something way less than halfway to that line.
[deleted]
Agree on the software case. Disagree about the recipes.
Food writing is its own genre where the recipe is one part of a larger story. Can often include travel stories as well.
Maybe not your thing. But definitely has its place.
Food writing is its own genre where the recipe is one part of a larger story. Can often include travel stories as well.
Maybe not your thing. But definitely has its place.
Can we agree that this flavor of recipe writing should not be applied to software? That's the point I was going for (hence the ad absurdum header)
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 similar I didn't look up the exact quote, attributed to Feynman). If you're polishing something up to make it understandable that's totally different than polishing it up to make yourself seem smart, right?
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.
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.
"So I was thinking about #####'s Law this morning, and I realized that #######'s Theorem might apply if we do this and ignore that. Then I went up a blind alley and stopped for coffee and realized I was overcomplicating it, we don't care about negative or imaginary solutions."
They don't need to know I was brushing my teeth and thinking of bacon and an argument I had with my spouse right before I thought that though. Or how rude the customer in front of me was to the new barista who was just trying her best.
They don't need to know I was brushing my teeth and thinking of bacon and an argument I had with my spouse right before I thought that though. Or how rude the customer in front of me was to the new barista who was just trying her best.
I personally stumble upon many topics where I only care about the what.
In that case all the theory is just a distraction I'm just wading through to get to the point.
If it's optional, then looking into the how and why is certainly nice, but it should be part of an appendix or a commentary and not interspersed within the proof unless an uncommented version exists.
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.
It makes one vulnerable though, that's for sure. Psychologically I mean.
Whether you realize it or not, you're insisting all the neurodivergent people at your job unmask themselves, and fuck that noise.
I'm nuerodivergent, I dream of a world where not only can they unmask, but that normal folk will see the intricate chaotic beauty behind it.
Probably a pipe dream though.
But for sure I don't want to force it on people.
Don't use the feature if you don't want to, I'm all about freedom of choice.
Just saying the upside to it.
Probably a pipe dream though.
But for sure I don't want to force it on people.
Don't use the feature if you don't want to, I'm all about freedom of choice.
Just saying the upside to it.
So I want to be clear that I'm not destroying other people's ability to learn from me. I just don't tell the entire story in the code, but I'm open about it if you talk to me. It's not a long conversation to figure me out. If it was I'd consider that a failure to do my job properly.
I know I'm done with a module when people add features to it the way I would have done so. That sounds like a non-statement, but I bet if you watch your projects closely, you'll see that's often not the case and sometimes it's laughably bad. It goes along with Knuth's thing about code meant to be read by humans and incidentally by computers, and also Kernighan's Law. My code eventually just says exactly what it does. And I don't use the same noun to mean three different things in three different places. Why? Because then I can take my name off of the bus number list and pick something else up. This module that I wrote is Steve's baby now, and that one is David's. In fact taking it over is how David got promoted.
I know I'm done with a module when people add features to it the way I would have done so. That sounds like a non-statement, but I bet if you watch your projects closely, you'll see that's often not the case and sometimes it's laughably bad. It goes along with Knuth's thing about code meant to be read by humans and incidentally by computers, and also Kernighan's Law. My code eventually just says exactly what it does. And I don't use the same noun to mean three different things in three different places. Why? Because then I can take my name off of the bus number list and pick something else up. This module that I wrote is Steve's baby now, and that one is David's. In fact taking it over is how David got promoted.
Maybe the person reviewing your PR is too busy to also provide therapy for your internal thoughts while writing the code?
People barely read PRs at most places I've worked.
The only reason they'd go deeper is for a bisect, or some other analytical method.
At least one day I hope they level up to be able to do that.
It's a golden rule thing for me.
I like more information because it's easier to filter too much data, than to reconstruct destroyed information.
The only reason they'd go deeper is for a bisect, or some other analytical method.
At least one day I hope they level up to be able to do that.
It's a golden rule thing for me.
I like more information because it's easier to filter too much data, than to reconstruct destroyed information.
I cook my own commits 75% for me six months from now and 25% for everyone else. I'm literally only doing about 1/3 more work (on the therapy part) than I would have done anyway.
health inspector is a literal job that needs to know how messy the process of making the sausage is, so they can enforce health standards so nobody gets sick when eating it.
if you're calling what you're doing engineering, you are following a standard best practice, and should easily be able to run through a checklist and show your work at each step.
not every thought needs to be expressed sure. its irrelevant what you thought about your lunch. Its important how you picked what latency numbers are important, and how you went about predicting volume, including what factors your did and didnt look at.
software developers havent been rigourous engineers over the last several decades, and that isnt a good thing
if you're calling what you're doing engineering, you are following a standard best practice, and should easily be able to run through a checklist and show your work at each step.
not every thought needs to be expressed sure. its irrelevant what you thought about your lunch. Its important how you picked what latency numbers are important, and how you went about predicting volume, including what factors your did and didnt look at.
software developers havent been rigourous engineers over the last several decades, and that isnt a good thing
No arguments here. The weird thing is that this was all much more straightforward when we did trunk-based development. You still ended up stashing four different things and having multiple speculative local branches while you tried your crazy ass ideas out, and Mikado Method was your very best friend.
What ended up happening is you committed the safe bits and the reversible decisions first to buy yourself time to work out the tricky bits before you had to commit (literally and figuratively).
I think trunk-based development is greater than PRs, but the values are close enough that the politics of PRs (specifically, consensus-based development) win out, or at least aren't worth fighting.
What ended up happening is you committed the safe bits and the reversible decisions first to buy yourself time to work out the tricky bits before you had to commit (literally and figuratively).
I think trunk-based development is greater than PRs, but the values are close enough that the politics of PRs (specifically, consensus-based development) win out, or at least aren't worth fighting.
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.
Ya, their coding harness is way better than Claude code, but because it’s directly using the clause api it’s way more expensive. Rolling it into the family would make it product-class-defining.
[deleted]
> 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.
Why stop at zed? The trillion dollar investment AI companies have amassed was nominally for datacenters, but as those costs rise and completion timelines extend past the typical business planning horizon, it becomes more efficient to put the money to work elsewhere. You can buy whatever you want with a trillion dollars.
Why stop at zed? The trillion dollar investment AI companies have amassed was nominally for datacenters, but as those costs rise and completion timelines extend past the typical business planning horizon, it becomes more efficient to put the money to work elsewhere. You can buy whatever you want with a trillion dollars.
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?
I personally want better read-only code tools, or maybe the return of UML?
I think it's the other way around. OpenAI is definitely recreating the IDE from scratch with codex app.
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.
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.
They drove up to my house with a dump truck full of money... Im not made of stone!
A commit is useful because you cleaned it up first. The messing around in between is where you try things and delete the dead ends and most of it is meant to be thrown away. Saving every change and every agent message keeps all that junk around instead.
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.
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.
They do have work to do, but micromanaging the developers is easier, so that’s what they do.
Google has been doing this for maybe a decade now with citc [0]. I don't know when Gemini is actually going to be taking advantage of this, but I do know that google has essentially a full history at "Ctrl-S" granularity, from ~every developer that works there, for at least 10 years now.
If Gemini seems stupid nowadays, it's only because they're being stingy with compute allocation.
0 - https://en.wikipedia.org/wiki/Piper_(source_control_system)
If Gemini seems stupid nowadays, it's only because they're being stingy with compute allocation.
0 - https://en.wikipedia.org/wiki/Piper_(source_control_system)
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 us. With a good model and the extremely good guardrails our of specific coding harness, LLMs are writing the majority of our code these days.
So on a typical day I'll grab a ticket off the top of the stack, point my LLM at it, and start working with it to solve the problem. We'll make architectural decisions, etc, create a plan and execute the plan. The feature I shipped most recently cost $19 in tokens and the LLM was churning without my input for like half an hour at one point in the thick of it.
MAYBE if there's a question I'm not sure which way is best I'll post a question in the team chat for my teammates to weigh in on. But a lot of my tickets are done completely autonomously.
Then I'll open a PR, and post a link to the PR in Slack, requesting their review and my teammates will see the implementation for the first time. They sometimes have questions! Often, they'll post these questions in the Slack thread rather than as PR comments, because we're having a fast real-time conversation and GitHub comments aren't a great fit for that.
These questions have answers in the chat log with the LLM that lives on my laptop, but I can't trivially show it to them.
So I end up playing telephone with the LLM -- copying my teammate's questions from Slack to the LLM chat, pasting the answers back, etc
The idea that my coworkers and the LLM and I can all be more easily a part of the same conversation appeals to me greatly
None of this means the Zed team is on the right track. Nor that my team might work better in a different way! But we're too "successful" with this approach for there to be much institutional pressure to change our ways at the moment.
Hope that helps.
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 us. With a good model and the extremely good guardrails our of specific coding harness, LLMs are writing the majority of our code these days.
So on a typical day I'll grab a ticket off the top of the stack, point my LLM at it, and start working with it to solve the problem. We'll make architectural decisions, etc, create a plan and execute the plan. The feature I shipped most recently cost $19 in tokens and the LLM was churning without my input for like half an hour at one point in the thick of it.
MAYBE if there's a question I'm not sure which way is best I'll post a question in the team chat for my teammates to weigh in on. But a lot of my tickets are done completely autonomously.
Then I'll open a PR, and post a link to the PR in Slack, requesting their review and my teammates will see the implementation for the first time. They sometimes have questions! Often, they'll post these questions in the Slack thread rather than as PR comments, because we're having a fast real-time conversation and GitHub comments aren't a great fit for that.
These questions have answers in the chat log with the LLM that lives on my laptop, but I can't trivially show it to them.
So I end up playing telephone with the LLM -- copying my teammate's questions from Slack to the LLM chat, pasting the answers back, etc
The idea that my coworkers and the LLM and I can all be more easily a part of the same conversation appeals to me greatly
None of this means the Zed team is on the right track. Nor that my team might work better in a different way! But we're too "successful" with this approach for there to be much institutional pressure to change our ways at the moment.
Hope that helps.
If you're just a middle man between your coworkers and the LLM, what's the value you're bringing to the team?
I think of a PR as something akin to a lab report. I put myself in the shoes of the reviewer and everything not immediately clear from the title and the diff, I would write an explanation in the description of the PR. That reduces the need for back and forth.
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.
Which makes more sense I think than describing it as an alternative for Git PRs.
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.
It feels like this communications problem could be solved through draft PRs and a decent slack app integration.
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 should all be evident from your codebase. It’s not an extra thing. It’s not a bunch of commit messages or ADRs. If your codebase isn’t entirely self explanatory (both the what and the why) to both humans and AIs you’ve failed and will spend your whole life creating more and more process to manage that failure.
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.
The current state of the code is not sufficient for modern software development.
At least we agree “modern software development” is the root cause.
If that works for someone, great. I would never pay for it, and would run not walk away from any shop that asked me to use it. The mess in-between working software is not something I care to have version controlled.
Many years ago I helped a friend with some draft that had to do with him finishing his doctorate. It ended up being maybe 50-60 between three of us and as fine grained as possible.
That agents need something "beyond git" is lost on me but it keeps coming up. For one subject the tool doesn't matter -- in fact it can be obtuse like git or bash and it's fine because agents will handle it. Then for another thing the story is opposite.
That agents need something "beyond git" is lost on me but it keeps coming up. For one subject the tool doesn't matter -- in fact it can be obtuse like git or bash and it's fine because agents will handle it. Then for another thing the story is opposite.
The interesting question is whether agents actually benefit from finer-grained history or whether they're better served by semantic checkpoints – "this works, this doesn't" rather than line-by-line diffs. Git wasn't designed for that, but neither is anything else yet.
If works/doesn't are semantic checkpoints, then I use that every day for myself with Git notes.
Sad to see zed going the same route everybody is screaming them not to. Altough, I never expected otherwise.
What route is that, and why is everyone screaming at them, for someone out of the loop?
Like others, I really like Zed as a text editor. I was a Sublime user before but I switched to Zed because it was even faster and cleaner than Sublime. The multi-buffer editing is a nice step up of multi-cursor editing. I just want a fast text editor with a few conveniences for development.
I don't care about any of the collaboration or AI tools that they are working on and I hope that these efforts don't detract from the text editor. At the very least I hope I can hide these features in the UI and continue to ignore them. I also hope that these features don't lead to a bloated, sluggish text editor like VSCode and IntelliJ.
I don't care about any of the collaboration or AI tools that they are working on and I hope that these efforts don't detract from the text editor. At the very least I hope I can hide these features in the UI and continue to ignore them. I also hope that these features don't lead to a bloated, sluggish text editor like VSCode and IntelliJ.
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
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
I've built some skills to help work with multiple repos, but it's really annoying how e.g. repo-specific .claude/ configs are only read when you start the agent in the repo folder. There's a ton of low hanging fruit to improve dev experience.
I came across the conclusion here since a change sometimes spans several repos, per-repo history optimizes the wrong target.
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.
Where are these developers who are willing to talk to you about your code and hash out ideas? Everyone I’ve ever worked with is always too busy, too many other priorities. Sounds nice though.
Unrelated: I started using Zed a few weeks ago and really love it, it is everything it promises to be.
Unrelated: I started using Zed a few weeks ago and really love it, it is everything it promises to be.
Like most/all engineers (I assume), I have entire notebooks that are filled front to back and in the margins with scratch. Random calculations and notes, equations running into each other, any piece of information that was too fleeting to stay in my head or overspill from an already full working memory.
Most engineers I know keep such notebooks when they're full, because it's kind of neat to open a random page and see a brain dump scrawled out. Nobody has ever looked at another engineer's scratch notes and drawn useful insight. Frankly, I wouldn't even want to other than for novelty.
Most engineers I know keep such notebooks when they're full, because it's kind of neat to open a random page and see a brain dump scrawled out. Nobody has ever looked at another engineer's scratch notes and drawn useful insight. Frankly, I wouldn't even want to other than for novelty.
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.
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.
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.
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.
> Before agents, it was easier to believe that the ceremony of trading comments on snapshots was an effective way to collaborate on software,
I’m highly skeptical of this claim. For any complicated feature, there’s always a design doc (or an RFC, or a wireframe) and that’s what people used for discussion. Discussion in a PR are mostly about whether to accept the code, reject the feature, or provide feedback about alternate implementations. It’s not for pair programming or directing design.
Collaborating together in a research lab (brainstorm session) is not the same as asking feedback for a journal article (PR). What is described in the article is pair programming with extra steps.
I’m highly skeptical of this claim. For any complicated feature, there’s always a design doc (or an RFC, or a wireframe) and that’s what people used for discussion. Discussion in a PR are mostly about whether to accept the code, reject the feature, or provide feedback about alternate implementations. It’s not for pair programming or directing design.
Collaborating together in a research lab (brainstorm session) is not the same as asking feedback for a journal article (PR). What is described in the article is pair programming with extra steps.
> What we're really after is simple: the conversation with the agent becomes the only conversation you need to have.
This benefits those who make the machines you have conversations with and those that invest in them.
This benefits those who make the machines you have conversations with and those that invest in them.
I would be interested in a clear statement about how this scales. I've not used this workflow myself, but I've seen teams that did it. Whether they got huge benefits out of it I don't know, but I do know that watching them, I was not jealous of what I saw. If I make a change, and I run some tests that were passing a moment ago, and they fail, and the reason why they failed is that Bob hit "save" on his editor (or his editor autosaves) and he made a syntax error in a shared library, and this happened often... I would go insane. I cause enough problems for myself without other people's problems actively intruding at uncontrolled times into my tests.
AI's code writing velocity makes this even worse, there's no way I can be simultaneously working on a code base while an AI agent is running around it doing something else.
It feels like maybe there's a ghost of an idea here about how to get the best of both worlds, but I'm not sure I follow the throughline on it.
AI's code writing velocity makes this even worse, there's no way I can be simultaneously working on a code base while an AI agent is running around it doing something else.
It feels like maybe there's a ghost of an idea here about how to get the best of both worlds, but I'm not sure I follow the throughline on it.
I really like Zed. It's customisable enough for me to make it look how I want, it's faster than every other editor I've tried (scrolling is silk, zero lag anywhere), it has enough features that I don't need an IDE (debugger, refactoring tools), and it generally gets out of my way.
I also like the AI tools, the inline assistant is good and the agent is also pretty nice and well integrated into the editor without it being the focus point. I'm not against using AI but I certainly don't use it as much as a lot of people do.
That being said, I really dislike this recent push towards becoming more like a cursor wannabe. They have a new (for now) opt-in default layout that almost hides the editor panel in favour of the agent threads and agent panels. And now this. I don't want to switch editors, but if they keep pushing a different workflow from what I use it might send me back to Jetbrains...
I also like the AI tools, the inline assistant is good and the agent is also pretty nice and well integrated into the editor without it being the focus point. I'm not against using AI but I certainly don't use it as much as a lot of people do.
That being said, I really dislike this recent push towards becoming more like a cursor wannabe. They have a new (for now) opt-in default layout that almost hides the editor panel in favour of the agent threads and agent panels. And now this. I don't want to switch editors, but if they keep pushing a different workflow from what I use it might send me back to Jetbrains...
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 only really useful for things that were 100% on the web, it never caught on with the more file-centric workflows. It works in something like Google Docs because it's natural that your data is in the cloud there, but for something that lives on your filesystem it feels like it takes extra steps that most people aren't going to be willing to do (especially if they have to use an editor different from their normal one)
I guess it would be perfect for pair programming in a remote work environment.
This seems like a great way to facilitate data gathering for improving LLMs coding performance.
If previously you needed to take action 1, 2, 3 to go from state A to B, all you saw was the change from A, B. Now you see intermediates 1, 2, 3 and can train the models to skip straight to B with the added context of the intermediate states.
If previously you needed to take action 1, 2, 3 to go from state A to B, all you saw was the change from A, B. Now you see intermediates 1, 2, 3 and can train the models to skip straight to B with the added context of the intermediate states.
> the conversation that generates the code is becoming the true source of our software
This is close, but not quite spot on. I've found that I'll test more ideas _with code_ using agentic tools, then before, leading to an excess of conversation history that is no longer representative of the final outcome.
A simple example I encountered recently was dealing with performance issues on an iOS application (I haven't written mobile code since before Swift..). If you viewed the chat, you'd dive down a diverging path of rabbit holes, few of which were relevant to the final outcome[0].
To solve this in my own work, I've started relying on "context hierarchy" - which is essentially live documentation that lives next to the source files (using markdown).
This approach avoids comments being removed erroneously, and helps codify the intent behind the code and how it relates to the overall architecture. As an added bonus, it also forces the LLM to edit _two_ things instead of just one (which might actually be the biggest benefit).
My workflow is currently maintained via some repo level scripts and AGENTS.md prompts, but I've tried to pull it out into a skill for others to use[1].
Candidly, I'm not sure the skill is the best approach yet, as the agent can sometimes get too focused on the "skill" as a separate tool rather than a core part of the workflow. I'm currently exploring other options here (repo bootstrap, side-loaded subagents, hooks, etc.)
[0]For more context, I was using a 3rd party library and trying to make it performant during a streaming operation, by removing the SwiftUI view layer (LazyVStack) and implementing a custom rendering path with UIViewController. The final solution ended up as a custom implementation of the 3rd party library, and moving back to LazyVStack.
[1]https://github.com/jumploops/chum
This is close, but not quite spot on. I've found that I'll test more ideas _with code_ using agentic tools, then before, leading to an excess of conversation history that is no longer representative of the final outcome.
A simple example I encountered recently was dealing with performance issues on an iOS application (I haven't written mobile code since before Swift..). If you viewed the chat, you'd dive down a diverging path of rabbit holes, few of which were relevant to the final outcome[0].
To solve this in my own work, I've started relying on "context hierarchy" - which is essentially live documentation that lives next to the source files (using markdown).
This approach avoids comments being removed erroneously, and helps codify the intent behind the code and how it relates to the overall architecture. As an added bonus, it also forces the LLM to edit _two_ things instead of just one (which might actually be the biggest benefit).
My workflow is currently maintained via some repo level scripts and AGENTS.md prompts, but I've tried to pull it out into a skill for others to use[1].
Candidly, I'm not sure the skill is the best approach yet, as the agent can sometimes get too focused on the "skill" as a separate tool rather than a core part of the workflow. I'm currently exploring other options here (repo bootstrap, side-loaded subagents, hooks, etc.)
[0]For more context, I was using a 3rd party library and trying to make it performant during a streaming operation, by removing the SwiftUI view layer (LazyVStack) and implementing a custom rendering path with UIViewController. The final solution ended up as a custom implementation of the 3rd party library, and moving back to LazyVStack.
[1]https://github.com/jumploops/chum
The approach sounds interesting but perhaps still too focused on current development paradigms.
Where shared collaboration I think becomes much more interesting is when agents start behaving like a member of your team. Not someone you delegate to, but someone that actively seeks out conversations and interacts with others as though they're just another member of the team.
You shouldn't be aware that version control is happening behind the scenes, you're just interacting with a persistent persona through Slack/teams/notion/figma/linear/etc with something that's logging issues, fixing bugs, writing PRDs, designing mockups, etc. The only point at which you know there's version control is when you're asked to review something before it's integrated.
Where shared collaboration I think becomes much more interesting is when agents start behaving like a member of your team. Not someone you delegate to, but someone that actively seeks out conversations and interacts with others as though they're just another member of the team.
You shouldn't be aware that version control is happening behind the scenes, you're just interacting with a persistent persona through Slack/teams/notion/figma/linear/etc with something that's logging issues, fixing bugs, writing PRDs, designing mockups, etc. The only point at which you know there's version control is when you're asked to review something before it's integrated.
Well shoot, they beat me to the punch. I’d been circling around something like this, just not collaborative and obviously more thought out than my random experiments. Minus the collab portions I’m interested to see how it compares to jujutsu
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.
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.
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.
> 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.
someone with your nickname would say :)
I can see how this is a great building block for what Zed is doing around collaboration.
One thing I would really love to see, however, is a way to better attach code review comments to the specific version of code they were left on. I find it quite difficult to do with git and github, considering that commit hashes change every time one is forced to rebase (say, for example, to handle a merge conflict).
Do you expect DeltaDB to help address this problem?
One thing I would really love to see, however, is a way to better attach code review comments to the specific version of code they were left on. I find it quite difficult to do with git and github, considering that commit hashes change every time one is forced to rebase (say, for example, to handle a merge conflict).
Do you expect DeltaDB to help address this problem?
A bit O/T but:
> I have never been a big fan of pull requests.
I guess this partly explains why Zed (still) lacks a PR review flow, let alone a coherent one, despite some interest [1]. Pretty much the only reason I’m still with JetBrains.
[1]: https://github.com/zed-industries/zed/discussions/34759
> I have never been a big fan of pull requests.
I guess this partly explains why Zed (still) lacks a PR review flow, let alone a coherent one, despite some interest [1]. Pretty much the only reason I’m still with JetBrains.
[1]: https://github.com/zed-industries/zed/discussions/34759
I hate software tools now. I really do. A hammer would never ask you to think about it constantly. If you think about your hammer it’s because something is wrong with it.
It's not just tools. Pretty much all software is like that.
The problem is, is that it works, if you assume "working" means the software sellers get wealthy.
There's a reason that most waitstaff wear black. They should blend into the background, and not be what the folks at the table are talking about. In rare instances, restaurants exist, where the waitstaff is the service.
In software, though, you're being served by a waiter wearing a clown suit, screaming slogans at you, and serving you lukewarm, pre-chewed goo.
The problem is, is that it works, if you assume "working" means the software sellers get wealthy.
There's a reason that most waitstaff wear black. They should blend into the background, and not be what the folks at the table are talking about. In rare instances, restaurants exist, where the waitstaff is the service.
In software, though, you're being served by a waiter wearing a clown suit, screaming slogans at you, and serving you lukewarm, pre-chewed goo.
My favorite new-to-me cathartic feature is Safari’s hide distracting items.
Probably easier with an ad blocker or just Reader view. But I really enjoy tapping on all the overlays and moving ads and videos and see them evaporate one by one, leaving just the text I wanted to read.
The default state of the page is much like the restaurant you describe.
Probably easier with an ad blocker or just Reader view. But I really enjoy tapping on all the overlays and moving ads and videos and see them evaporate one by one, leaving just the text I wanted to read.
The default state of the page is much like the restaurant you describe.
I use OpenBSD as a daily driver (but could use Alpine or VoidLinux too) and my setup is pretty much silent. No notifications, no rainbows of colors, no glitz. Let’s take mail. I use a combination of mutt hto directly connect via imap) and fdm/mu4e (to have them locally). I”m not interested in having counters or notifications for any of those.
The “calm technology” book has an handful of advices, but one of the best example is the xbiff program. It switches picture when you have new mail on your local spool.
The “calm technology” book has an handful of advices, but one of the best example is the xbiff program. It switches picture when you have new mail on your local spool.
Ah, McDonald’s isn’t that bad.
> A hammer would never ask you to think about it constantly
A table saw does tho.
A table saw does tho.
From a Casey m podcast I think of agentic driven software dev as code extrusion. I guide and massage the steady output of content
I think this makes a lot of sense in the context of Zed’s multiplayer editing. Maybe that works well for a small team working on a single product, but that doesn’t seem like it’d scale super well. I loved tight collaboration long ago on online notepads despite constantly breaking stuff for each person…
With Gerrit, you have the patch that lands on master and then you have the stages that that patch went through to get to that point, reviews on older versions of the patch, etc. all recorded in the web interface.
So maybe just switch to a code review tool and use its interface to converse with the bots?
So maybe just switch to a code review tool and use its interface to converse with the bots?
This seems like such a weird article. Software is made at build time, which is usually due to a cicd process in place, which is dependent on committing code. It works. There’s no magical way of avoiding the idea that code usually exists in a commit someplace without proper justification.
> DeltaDB captures every operation in between and gives each one a stable identity
Gives jj vibes, interesting!
Gives jj vibes, interesting!
especially when using Watchman https://docs.jj-vcs.dev/latest/config/#watchman
Just a stream of thoughts: if git commits were a list of sequential primitive changes instead of diff snapshots, conflict resolution would be trivial in most cases.
Not without cons of course: commit byte size, public WIP work and leaked secrets/unwanted edits.
Not without cons of course: commit byte size, public WIP work and leaked secrets/unwanted edits.
This seems exactly backwards. Most commits should not exist, because the majority of people can't already help themselves from committing "wip" "fix lint", let alone anything more granular.
What is apparent to me is that we are moving towards dark factories if the promise of LLMs writing most of the code is fulfilled. So this means that it is less about conversations and it is more about iteration.
I totally see where they are coming from, jitsu, too is making every change its own artifact. And it plays hard to the "faster shipping" that especially AI-driven teams are pushing hard, and find the review process to be the next big bottleneck now (as I just saw with my last client as well).
There has also been a lot of discussion about the value of the peer review process recently, in in general. But I wonder if this isn't all going into the wrong direction. Quite honestly, even with the previous review and discussion system of (squashed) commits how often did you really use git blame and opened up the original PR discussion of that changed line that caused the bug? And how often did it help you beyond learning it was done by that rockstar developer who has left long ago? And that the discussion on that PR was a point in time and the code around it has evolves beyond that and it would need looking at another 10 PR discussion to get the entire context.
What I am saying is that git (and before that Subversion and CVS) has a full history is so that it can resolve the latest state. Period. We made that commit ritual somewhat of a hallmark in putting more supposed meaning into recording ever more in that history. But we rarely stopped to check if that is all that useful. Recording even more, all the time, reminds me of these work group meetings that have minute records of every bike shedding meeting word said by everyone, that, honestly, no one ever looks at after the next meeting ever again. I don't think there is value in minute record keeping, it becomes too much noise that just makes it harder to parse. Now also adding all AI conversation and agent thinking to that tree? What's the value of that in like 3 months down the line? I don't see it.
There has also been a lot of discussion about the value of the peer review process recently, in in general. But I wonder if this isn't all going into the wrong direction. Quite honestly, even with the previous review and discussion system of (squashed) commits how often did you really use git blame and opened up the original PR discussion of that changed line that caused the bug? And how often did it help you beyond learning it was done by that rockstar developer who has left long ago? And that the discussion on that PR was a point in time and the code around it has evolves beyond that and it would need looking at another 10 PR discussion to get the entire context.
What I am saying is that git (and before that Subversion and CVS) has a full history is so that it can resolve the latest state. Period. We made that commit ritual somewhat of a hallmark in putting more supposed meaning into recording ever more in that history. But we rarely stopped to check if that is all that useful. Recording even more, all the time, reminds me of these work group meetings that have minute records of every bike shedding meeting word said by everyone, that, honestly, no one ever looks at after the next meeting ever again. I don't think there is value in minute record keeping, it becomes too much noise that just makes it harder to parse. Now also adding all AI conversation and agent thinking to that tree? What's the value of that in like 3 months down the line? I don't see it.
I often find it helpful to see the entire commit and message leading to a specific line of code getting into its current state.
That’s about it.
That’s about it.
This is what I’ve been thinking of ever since coming across Ramp’s agent[1] and other orgs trying to build their own remote dev envs with agents at the center. Makes so much more sense in this kind of a dev spree to not wait for a PR. Because all actors end up repeating the same thing with their own agents which can be totally avoided. Conversations and code to jump in and out of, to collaborate etc seems like the right way to go.
Excited to see what Zed team comes up with! :)
[1]: https://builders.ramp.com/post/why-we-built-our-background-a...
Excited to see what Zed team comes up with! :)
[1]: https://builders.ramp.com/post/why-we-built-our-background-a...
Zed are doing a great job at making the exact things developers don’t want. It’s clear that their focus is on raising funding rather than making a great text editor.
I love the title, there was another post that I thought was clever “If You are Asking for Human Attention, Demonstrate Human Effort”
With LLMs now being responsible for the physical typing of code and mundane plumbing tasks, this is a wise direction to go into
Our human ability is not defined by our _absolute_ output, but, by the quality of the _delta_ applied to an engineering artefact
Great engineers obsess over every keystroke
With LLMs, a much smaller number of keystrokes can create a much larger and more positively impactful delta
Every delta to the codebase can tell us some informational property about the behaviour of the system and storing that information WILL prove to be useful in the future
Our human ability is not defined by our _absolute_ output, but, by the quality of the _delta_ applied to an engineering artefact
Great engineers obsess over every keystroke
With LLMs, a much smaller number of keystrokes can create a much larger and more positively impactful delta
Every delta to the codebase can tell us some informational property about the behaviour of the system and storing that information WILL prove to be useful in the future
Sounds like "google docs with code formatting".
I didn't see anything in there about branching which seems like a big thing not to have.
I didn't see anything in there about branching which seems like a big thing not to have.
I swear a lot in my chats with Claude..
The work product is not the work.
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.
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.
No, software is made in the choice of what to keep in the final commit.
I'm glad to see this feature and looking forward to see how it evolves.
Many of the product decisions that Zed's made caused me to switch to Zed for my daily driver IDE (previously JetBrains). The recent AI agent threads and improvements around diffs really solidified the move.
Many of the product decisions that Zed's made caused me to switch to Zed for my daily driver IDE (previously JetBrains). The recent AI agent threads and improvements around diffs really solidified the move.
JetBrains’ AI offering peaked last year when Junie was briefly better than Codex. Now it’s a wash.
Honestly all of this drives me back towards nvim or notepad sometimes.
I have had a jetbrains subscription since pycharm came out, and the killer feature was always the visual debugger. Seems nearly quaint now.
What specific things do you like about zed?
Honestly all of this drives me back towards nvim or notepad sometimes.
I have had a jetbrains subscription since pycharm came out, and the killer feature was always the visual debugger. Seems nearly quaint now.
What specific things do you like about zed?
Agents can certainly use a new substrate as they can eat dense information quickly.
Not convinced DeltaDB is useful for humans directly but assume new and interesting interfaces can arise from the abstractions it provides.
Agree that PRs/snapshots is an antiquated way of sharing information.
Not convinced DeltaDB is useful for humans directly but assume new and interesting interfaces can arise from the abstractions it provides.
Agree that PRs/snapshots is an antiquated way of sharing information.
Could you just give me reference peeking without opening a full tab?
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
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
I think this is a cool approach, like a giant undo stack.
Just what we need, a new kind of version control %]
The door is open when it isnt shut.
I'll probably get more hate for saying this but fine: I use Zed 50% of the time (the other 50% dedicated to vim) for two reasons:
1. It is fast and snappy. Nothing comes even close besides vim (and I don't mind going full time to it if I have to)
2. The ability to completely shut off and block any slop machine features from interfering with my workflow or leak code back to sloppenai, sloppus or any other self-installed-worst-security-practice-backdoor garbage.
Having said that, I hope they don't remove that ability in the future and enforce the "slop is so good man, you should try it" philosophy.
1. It is fast and snappy. Nothing comes even close besides vim (and I don't mind going full time to it if I have to)
2. The ability to completely shut off and block any slop machine features from interfering with my workflow or leak code back to sloppenai, sloppus or any other self-installed-worst-security-practice-backdoor garbage.
Having said that, I hope they don't remove that ability in the future and enforce the "slop is so good man, you should try it" philosophy.
there is a fork of zed against ai: https://gram-editor.com/
I am happy about even though I've never tried gram, because if zed goes to shit there will be an alternative, which hopefully pressures zed to stay sane
I am happy about even though I've never tried gram, because if zed goes to shit there will be an alternative, which hopefully pressures zed to stay sane
From their mission statement:
> I also object to making myself and my work depend on paying a subscription fee to anyone. I don't want an outage at Anthropic to affect my ability to do my work. I think it is a grave mistake to build anything on such shaky foundations as the sustainability and profit margins of the AI industry.
Someone actually sensible, excellent.
> I also object to making myself and my work depend on paying a subscription fee to anyone. I don't want an outage at Anthropic to affect my ability to do my work. I think it is a grave mistake to build anything on such shaky foundations as the sustainability and profit margins of the AI industry.
Someone actually sensible, excellent.
That’s not the premise people are building on though.
Any particular model almost doesn’t matter at this point. Harnesses are built around them. OpenAI and Anthropic are basically interchangeable in an open-source harness like OpenCode; the switching cost is virtually zero. Local models are improving rapidly and are already “good enough” for many use cases already. The bet that LLMs will continue to exist as an algorithm is pretty solid.
Any particular model almost doesn’t matter at this point. Harnesses are built around them. OpenAI and Anthropic are basically interchangeable in an open-source harness like OpenCode; the switching cost is virtually zero. Local models are improving rapidly and are already “good enough” for many use cases already. The bet that LLMs will continue to exist as an algorithm is pretty solid.
Oh, that's a breath of fresh air. And they are on codeberg. Nice! Thank you!
Edit: After further inspection, I think I'm jumping ship before it's too late. And I'll look, see if there's a way to lend a hand or two when I have time!
Edit: After further inspection, I think I'm jumping ship before it's too late. And I'll look, see if there's a way to lend a hand or two when I have time!
Thank you for that link! Looks like it fixes all of my annoyances with Zed; I'll have to try it out.
Cool, didn't ever hear about it! Thanks for sharing.
i keep comitting when i make a change. who cares. im solo dev. svn. git no thanks.
Next up: a kit to wire up a developer's brain activity direct to the AI companies, so not a single part of their thought process remains in control of the developer, in order to feed the models. You must brainsignalmaxx 8 hours a day or be fired.
Your boss will also demand that you narrate your thought process 8 hours a day. Speakmaxxing will be required to keep your job. There will be a "silence" wall of shame for the non-compliers.
Your boss will also demand that you narrate your thought process 8 hours a day. Speakmaxxing will be required to keep your job. There will be a "silence" wall of shame for the non-compliers.
It is almost happening in a different way, for automating physical labor, some companies are collecting data by making people wear camera on their heads
The Indian workers training AI robots to take their jobs
https://www.youtube.com/watch?v=JQoPoLUJWic
The Indian workers training AI robots to take their jobs
https://www.youtube.com/watch?v=JQoPoLUJWic
Technically, this is true
Lmao an ad
I agree with the author that reviewing pull requests is too late. The problem with pull request is that they make it hard to review individual commits since they are geared towards reviewing the result of an entire branch at once. But the answer is not to share all the noise, it should be to encourage small atomic commits so you can review the early work before the entire feature/fix is complete.