hot take
The only reason "squashing commits" is such a widespread practice with Git now, is that tools like Github are incapable of displaying the commit graphs correctly, and insist on linear display
"The commit history becomes messy" wouldn't be a problem at all if the UI actually showed which commits occurred on a side branch, that's what it's *for*
follow-up hot take
I wonder how many abandoned PRs this particular Github design choice is (partly) responsible for; from people who just gave up after finalizing a PR and then being asked to squash their commits, and just being tired of the unnecessary busywork
follow-up hot take
@joepie91 But Github has a setting for repositories that automates the "Squash onto target branch" step. Why are people asked to do that manually?
At work, we have _very_ messy feature branches, mostly because they're owned by a single dev, and we sometimes get sloppy with descriptions when it's mostly "tie up some loose ends at the end of the work day". We have that option set, and all it asks us is to provide a text for the squashed commit, which defaults to the PR text.
re: follow-up hot take
@farhaven It does have that feature today (though not everybody uses it for some reason), but it didn't in the past, and various other project management systems that were modelled after the Github UI unfortunately haven't copied that feature yet either.
(Though even with auto-squashing, that only really resolves the follow-up comment; it still wrecks the history)
follow-up hot take
@joepie91 One reason I like fossil is it has an explicit position against rewriting history. I know it's possible to do this with git as well but the culture is very different.