Hacker News Reader

Comment by giancarlostoro | Hacker News Reader

I think it really depends on whose doing the commits, I've mostly worked with people who wont commit things that don't work so you see a lot less commits than you would expect. I prefer commits to be iterative and I prefer to see that if possible. I rather see 100 commits across dozens of files per commit vs 1 commit for 500 files.

View on HN

Depends on the situation entirely.

If I see a ton of commits like "fixing formatting" or "oops", I want those squashed away into proper commits.

If the changes you make are atomic in their own right and I can check out that commit, compile it, then run tests, and it passes. That's perfect. It works good for git-bisect, but the trick is to get everyone on board in the project to do that.

For public libraries I maintain, it's squash merges all the way. I like a clean history and the ability to check out that commit, compile, test, and run cleanly is perfect.

> If I see a ton of commits like "fixing formatting" or "oops", I want those squashed away into proper commits.

Every team I'm in I strongly advise against such commits honestly. They don't help anyone, I emphasize being able to find things you changed if you need to find them. You can even enforce a format for commits.

Funnily enough, I saw a wave of "fixes bug" "now really fixes bug" that got auto rejected by some commitcop utility at a former job, the guy was freaking out cause it wouldnt take all his changes. I guess they wanted to force him to stop doing such awful commit messages.

Commit messages should be useful and historically descriptive.

> Every team I'm in I strongly advise against such commits honestly. They don't help anyone, I emphasize being able to find things you changed if you need to find them. You can even enforce a format for commits.

Same with me, but people still ignore it.

plus, you can tell who doesn't use git bisect because they prefer a single large commit across 500 files to keep history clean.

As opposed to a series of small commits, that would make git bisect actually useful.

Why can't we just have some kind of "virtual squash" where the commits are preserved, but they're grouped together so you could view it as a single squashed commit if that's preferable?

Why not keep commits as the atomic element and use (release) tags if you want a coarse overview what happened?

That's a semi-linear history merge.

Your features are not broken down enough if one ticket requires hundreds of changes.

This is a solid argument. Except in cases where you're upgrading everything in a small to mid sized codebase that needs a major dependency updated that affects everything from syntax to other things, and cannot be done discretely.

For a Python 2 to 3 migration a few years back we did it in a branch with many commits. We didn't obsess about telling a story we just got the work done and the tests passing.

Before this there was some work to bring the codebase as close to 3.x paradigms as possible.

As long as the two points before and after the work are copacetic we were satisfied. In that sense it was discreet.

Reply on news.ycombinator.com