Fortunately, I don't squash my commits

Re:Fortunately, I don't squash my commits by FeepingCreature on Monday October 05, 2020 @07:46AM (#24686752)

I squash commits. Well, I rebase so that changes are logical rather than historical. This is because when people read the commit history, which actually happens regularly, they would actually like a complete story, not 15 commits of "fix audit", "fix review" and "fix typo" - let alone refactors where previous work in the PR is thrown out, which you can by definition never care about.

Commits so small that they're nonfunctional also break bisect.

[ Parent | on HN ]

Re:Fortunately, I don't squash my commits by twic on Monday October 05, 2020 @08:09AM (#24686938)

Nobody is suggesting you should make commits so small they're non-functional.

[ Parent | on HN ]

Re:Fortunately, I don't squash my commits by xorcist on Monday October 05, 2020 @10:16AM (#24687944)

Are you simply suggesting the removal of those non-functional commits to be called something else than "squashing"?

[ Parent | on HN ]

Re:Fortunately, I don't squash my commits by twic on Monday October 05, 2020 @11:40AM (#24688712)

I'm suggesting you don't make them in the first place.

If you do make them by mistake - and everyone does sometimes, certainly including me - then sure, commit --amend or squash them before pushing them up.

The squashing the article is talking about is collapsing functional, distinct commits into one when merging to the trunk. It would be useful if we had distinct terms for the two kinds of squashing; the git command commit --fixup and its associated interactive rebase operation suggest the name "fixups".

[ Parent | on HN ]

Re:Fortunately, I don't squash my commits by xorcist on Monday October 05, 2020 @12:08PM (#24689000)

The difference between fixups and squashing is only in how the commit message is generated.

Both are (interactive) rebase operations. Both are established terms in git, and it is probably not very useful to change that nomenclature now.

[ Parent | on HN ]

Re:Fortunately, I don't squash my commits by twic on Monday October 05, 2020 @01:41PM (#24690023)

They're the same technical operation, but they're used in different ways, and it's the difference in use that matters. It's useful to be able to distinguish them. It's never too late to improve our terminology! How long had git diff --cached been around when git diff --staged was introduced?

[ Parent | on HN ]

Re:Fortunately, I don't squash my commits by Nursie on Monday October 05, 2020 @02:05PM (#24690282)

When I read the commit history I want to see what was committed.

"Hmm, I had a half working X509 chain resolver there that turned out to be unnecessary at the time but would save me a day's work now..."

[ Parent | on HN ]

Re:Fortunately, I don't squash my commits by FeepingCreature on Tuesday October 06, 2020 @12:22AM (#24694658)

Keep it on a local branch?

[ Parent | on HN ]

Re:Fortunately, I don't squash my commits by Nursie on Tuesday October 06, 2020 @04:47AM (#24695846)

I'd moved workstation by then. If distributed source control is good for anything, surely it's reducing reliance on local state!

I don't think there's an easy answer here. I think there are good things to be said for a readable and bisect-able version history, but also that if you're not preserving your real commit history in a way that's backed up remotely then something's probably wrong.

I'm beginning to think this area, this schism into two schools of thought, is really a signpost that there's something lacking in git's branching. Or something everyone is missing, including me :)

[ Parent | on HN ]

Re:Fortunately, I don't squash my commits by barrkel on Monday October 05, 2020 @08:11AM (#24686967)

Bisect doesn't have a problem with intermediate broken states, actually. It's why git bisect skip exists. It may not be able to pinpoint an exact commit though.

[ Parent | on HN ]

Re:Fortunately, I don't squash my commits by alkonaut on Monday October 05, 2020 @08:17AM (#24687016)

Bisect does turn into my colleagues feature branch with 20 broken commits and unrelated content though, when I just want to bisect the main branch. That's infuriating and imho makes bisect almost useless. That there is no git bisect --first-parent is one of the greates mysteries of git.

[ Parent | on HN ]