They seem to have never worked with legacy code that has a good commit history you can rely on.
Arguing commits break flow would likely come from the same mouth that comments are useless and the code is self documenting. The "doesn't write code thinking of others" type.
Slack history and requirement documents are rarely linked in commit messages and looking through thousands of documents and channels to search the context of a commit is nauseating.
There's never a need to write an essay in a commit message, but 2-3 paragraphs won't kill anybody either.
(None of those links help when you switch to different providers; but that might not be too bad, depending on timescales of those changes)
at least in my current project working with legacy code that i am not familiar with, the why is the most important detail about a commit.
Other stuff like "this is ready, can you review it?", or "we can ship feature X now" lives in the other tools.
Note that (in the rare case where you want to), you can then search for links to old PRs in the other tools. Also, putting the jira ticket number in the commit message usually makes sense.
Why did I spend an hour refactoring 1000 lines of rust code again?
It worked the first time I got it to compile again, so it's probably fine, but it was a subtle non-functional change. I'd better commit + write a good message so:
- I don't forget why I just did that
- In case I need to back out the next step
- So that my coworkers know what I'm up to, and don't ask me on slack.
By default it will produce a commit message starting with `Squashed commit of the following:`
The contents of this message are staged in `.git/SQUASH_MSG`.
When using GitHub the squash merge commit behavior is configurable and the teams I've been on have kept it configured to keep the commit messages of the commits being squashed. I assume GitLab has similar functionality.