[jonkoops]

I have to disagree with this as it relies on the assumption that every commit on a branch is logical and descriptive. In my experience a lot of PRs will have small commits that have poor names as they go through a review process. If you merge this using a regular merge commit or by rebasing the commits on the target branch this creates a lot of noise for those who look at the commit history.

In my opinion it is best to squash all commits into one before rebasing it on top of the target branch. During this process any information that is considered important for the history can be preserved by leaving it in the commit body.

[omegalulw]

> I have to disagree with this as it relies on the assumption that every commit on a branch is logical and descriptive. In my experience a lot of PRs will have small commits that have poor names as they go through a review process.

There's your problem. Code reviews should not allow such commits to pass through.

[t3h2mas]

> Code reviews should not allow such commits to pass through.

Are you suggesting that your code review process has a stage for combing through commit messages? What does this look like? If the third commit message of 15 isn't up to par what happens?

[derekperkins]

You ask them to fix the commit message. Every git GUI should support that by now, so it should be a 1 minute fix, even for junior devs.

[rzwitserloot]

> I have to disagree with this as it relies

No, you didn't read the comment fully, or you only disagree with part of it. Because, you clearly missed this part:

> I still advocate for cleaning up and squashing your own commits as you see fit with an interactive rebase before your branch is merged.

If you do that, you don't end up with 'small, poorly named commits'. Or if you do, you have a lazy programmer / an idiot programmer in the team.

Which certainly happens, but, they ruin everything. You can't start shooting down processes, languages, tools, or anything else in the programmer space __just__ because some moron who abuses it ends up in a bad place. You need to show that a tool / feature / process / hook / etc turns otherwise fine, capable programmers into idiots in order to advocate for its abolishment. Not the other way around, or you end up with a blunt rock and a club and are then debating that they're holding the club at the wrong end.

[rectang]

As someone who carefully crafts my git history, I hate it when somebody smashes my work.