[klibertp]

> A git commit [ideally] gives you the reason for the change

FTFY ;) I broadly agree, but it's important to note that, in practice, Git commits are hit and miss: they might save you a lot of time if they are well-structured and described properly, but they might also completely fail to give you anything of value (for the problem you're facing at the moment). Turning Git history into a broadly useful artifact requires a lot of discipline from everyone working on a codebase over its lifetime.

It's never totally useless, but it's often less helpful than it could be.

Recently, I turned to JJ for this exact reason: crafting a meaningful change history is much easier there, especially if you need to retrofit it after you're done with the implementation. jj's split, squash, and describe are a joy to work with, also because the interactive version lets you easily split or squash hunks (selected changes in the same file).

[afavour]

Fair. Though I find it works well when commits get squished at the PR level. That way you have a link to a (hopefully!) detailed overview of what happened, when and why.