Git @programming.dev Mac @programming.dev 4 mo. ago

commit messages are optional

18 comments

But shouldn't be. How hard is it to summarize your work in a few words? Even a bad description is more memorable than a hash.
- The post mentions that these are for commits in a merge request before squash. When they’re squashed a proper message is given.
  
  Sure, but how much of that is justification and backpedaling?
  
  If it's worth a commit, it's worth a description. "Address vulns" "fix config" "remove files". It doesn't take much. Even if it's just "more address vulns".
  
  Also, squashing is a pretty bad practice as it is. I can understand that it may make sense sometimes, but most of the time if you don't commit every other character you input, you're better off leaving some history of how your code evolved and what changes were coming together
When I'm just locally iterating on stuff I'll usually do a git commit -m "WIP: Description of what I'm trying to do" and then git commit --amend to it. A bit more ergonomic than stashing if I want to switch branches imo. I can also go back to old versions if I want to through the reflog.

git commit --fixup some-commit is also great for if I discover things in the review for example. You can then do git rebase master --autosquash to flatten them into the commit they belong to and that way you don't have to bother with commit messages like "fixed typo". Doing fixups for small fixes is good because it allows you to keep your mr broken up into several commits without also leaving in a bunch of uninteresting history.

Can recommend checking out the --fixup section in the git documentation if you haven't heard about --fixup before.

You've viewed 18 comments.