News for hackers. Stuff that matters.
Re:git-appraise – Distributed Code Review for Git by OkayPhysicist on Friday August 11, 2023 @12:42PM (#37090732)
I've never gotten the point of squash-merge. The normal "merge into release branch, never fast-forward" workflow retains more useful information. Every release commit has 2 parents: the previous release commit, and the former head of the feature branch it got its changes from. If you want a chain of releases, you go down the path of commits labeled "RELEASE". If you want information on the changes, go down the other path.

I regularly use "git blame" on lines of code to try and figure out what the specific reasoning was on a line of code. I'm going to have a very different interpretation depending on if the resulting commit says "implement feature xyz" vs "fix issue abc on feature xyz".

Squash murders that added context. At best you're optimizing for the wrong thing, and worst it's outright vandalism.

Re:git-appraise – Distributed Code Review for Git by paulddraper on Friday August 11, 2023 @01:15PM (#37091164)
> I've never gotten the point of squash-merge.

1. Broken intermediate commits hamper git bisect.

2. Fixup commits are noisy in git log, git blame, etc.

Note: there's zero issue with NON-BROKEN, NON-FIXUP commits. Separating large changes is even preferable for the reasons you stated.

---

tl;dr Broken intermediate commits are bad; whole intermediate commits are good.