Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Software is made between commits

zed.dev

Post reply on HN
Print view View original

201–210 of 230 posts

Re: Software is made between commits

#201

Post by palata »

jasonkester wrote: post #194
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…

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

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

Re: Software is made between commits

#202

Post by palata »

gmueckl wrote: post #151
MaulingMonkey wrote: post #122

Earlier quoted context omitted.

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

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

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

Re: Software is made between commits

#203

Post by foobarbecue »

jasonkester wrote: post #194
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…

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

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.

Re: Software is made between commits

#204

Post by overtomanu »

gib444 wrote: post #102

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

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

Re: Software is made between commits

#205

Post by skydhash »

jasonkester wrote: post #194
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…

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

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

Re: Software is made between commits

#206

Post by [deleted] »

hinkley wrote: post #165
crimsonnoodle58 wrote: post #130

Earlier quoted context omitted.

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.

[deleted]

Re: Software is made between commits

#207

Post by skydhash »

jimbokun wrote: post #132
mplanchard wrote: post #27

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

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

They do have work to do, but micromanaging the developers is easier, so that’s what they do.

Re: Software is made between commits

#208

Post by wvh »

jasonkester wrote: post #194
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…

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

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.

Re: Software is made between commits

#209

Post by skydhash »

teach wrote: post #117
OtherShrezzing wrote: post #45

I don’t see the value proposition here. I’ve seen roughly this feature proposed by multiple companies, and absolutely none of the have given a convincing reason for the technology to exist.

It's interesting that your experience/workflow is so much different than mine. This (claims to) solve a real problem that I deal with every day. My company is remote-only, and my coworkers mostly don't live anywhere near me. We see each other a couple of times a day on video chat, but communicate mostly during the day via Slack. We're also, uh, pretty far along the curve in adopting LLM agents to write good code for…

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

Re: Software is made between commits

#210

Post by thomasfromcdnjs »

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…

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.

Post reply on HN