Software is made between commits • Hacker News Board

Re: Software is made between commits

#161

Post by seabass » Fri, Jun 12, 2026, 1:51 AM UTC

Lindby wrote: post #82

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

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

Re: Software is made between commits

#162

Post by hinkley » Fri, Jun 12, 2026, 1:54 AM UTC

jimbokun wrote: post #131

aeonik wrote: 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.

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

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.

Re: Software is made between commits

#163

Post by giraffe_lady » Fri, Jun 12, 2026, 1:56 AM UTC

jimbokun wrote: post #124

giraffe_lady wrote: post #64

Earlier quoted context omitted.

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.

Re: Software is made between commits

#164

Post by hinkley » Fri, Jun 12, 2026, 2:01 AM UTC

8note wrote: post #119

hinkley wrote: post #95

Earlier quoted context omitted.

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

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

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.

Re: Software is made between commits

#165

Post by hinkley » Fri, Jun 12, 2026, 2:03 AM UTC

crimsonnoodle58 wrote: post #130

hinkley wrote: post #53

Earlier quoted context omitted.

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

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

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

Re: Software is made between commits

#166

Post by hinkley » Fri, Jun 12, 2026, 2:04 AM UTC

giraffe_lady wrote: post #163

jimbokun wrote: post #124

Earlier quoted context omitted.

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.

If I look in your back yard right now, will I see a stolen giraffe?

Re: Software is made between commits

#167

Post by hinkley » Fri, Jun 12, 2026, 2:05 AM UTC

bmitc wrote: post #123

hinkley wrote: post #53

Earlier quoted context omitted.

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

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

> "fixed, added, deleted"

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

Re: Software is made between commits

#168

Post by hinkley » Fri, Jun 12, 2026, 2:07 AM UTC

Joker_vD wrote: post #143

bmitc wrote: post #123

Earlier quoted context omitted.

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

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

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

Re: Software is made between commits

#169

Post by hinkley » Fri, Jun 12, 2026, 2:12 AM UTC

jimbokun wrote: post #128

hinkley wrote: post #98

Earlier quoted context omitted.

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.

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)

Re: Software is made between commits

#170

Post by hinkley » Fri, Jun 12, 2026, 2:19 AM UTC

aeonik wrote: post #129

hinkley wrote: post #101

Earlier quoted context omitted.

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.

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.