Live data from Hacker News

Software is made between commits

zed.dev

121–130 of 230 posts

Re: Software is made between commits

#121

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

Yea, commits that go into a PR are generally just a sequence of logs and not necessarily a sequential stream of explicit steps.

Re: Software is made between commits

#122
post #49

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

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

Re: Software is made between commits

#123
post #53

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

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

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

Re: Software is made between commits

#124
post #53

Earlier quoted context omitted.

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

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?

Re: Software is made between commits

#125

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

Aren't you paid to think?

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.

Re: Software is made between commits

#126
post #118
post #76

Earlier quoted context omitted.

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.

why this particular object though? why didn't you add these three other parameters to it? how does this default value make sense when unset? mostly things that end up not-in-the-commit that 3 years from now people are gonna wonder about is really handy to know

I strongly doubt that.

Re: Software is made between commits

#127
post #123
post #53

Earlier quoted context omitted.

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

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

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

Re: Software is made between commits

#128
post #98
post #76

Earlier quoted context omitted.

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 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 tha…

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.

Re: Software is made between commits

#129
post #99

Earlier quoted context omitted.

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.

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.

Re: Software is made between commits

#130
post #53

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

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

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.

Post reply on HN