This looks entirely offtopic. Commenting on wrong post?

It sounds like a git joke about squashing vs merging.

It looks to me like GP may have commented without reading the article. "Mergers ruin everything" could be misread as "Merges ruin everything". Just reading the title could lead someone to think this was a discussion about git best-practices.

I was actually hoping for a nuanced view on code branch/merge tactics.

Got any suggestions on the topic?

I don't have any good resources off-hand (other than what shows up in a quick search), but my "best practices" are to always squash and keep PRs as small as possible.

When a working branch falls behind main, I prefer to rebase it instead of merging from main to keep it up to date. However, if you've already pushed your working branch to a repo, after rebasing you need to `git push --force` - which is a problem if there are others who have previously cloned the working branch.

Squashing also introduces problems when you are resolving merge conflicts in your branch: squashing doesn’t preserve merge conflict resolution so you end up having to resolve those conflicts again after merging.

Great comment and spot on. You can avoid the issue with force by using `—force-with-lease` which won’t push the force if there’ve been changes upstream.

That’s a bunch to type so I alias it to `fwl` In `~/.git config` and use it after rebases.