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”.
Often I commit because I have to jump to another branch, so I want to save my progress. This means I can be in the middle of something, so I write a trash message.
All those messages will disappear anyway after the merge request, because we use a squash policy. I can spend more time thinking of a more proper commit message when writing the merge request.
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
I think squashing is great and I would never want to go back. It helps ensuring:
All commits in main have useful messages. No more “fix pipeline errors”, “fix MR comments”, etc.
Ensures pipeline has been successful with all commits in main. No need to guess which commits will build and won’t build.
Easy to revert commits.
Eliminates incompressible history because someone had a bad day with git.
Encourages frequent commits. No need to ensure all commits are perfect and good in their own right. Commit when you want to commit even if it’s incomplete work.
And IMO, if your work warrants multiple commits, then it probably also warrants multiple merge requests. Merge requests should be rather small to make it easier to review.
Edit: another good thing is that when we decide to release, we can easily look through the commit history for a change log. No more sifting through minor fixes commits.
It’s more about the tooling. IDEs make it really simple.
Also people get scared when they hear it because of utterances like yours. I’m dumb af. Git rebase for your use cases can be renamed to “git edit-history $fromCommit”. Nothing special about it.
I agree with most of these but there’s another missing benefit. A lot of the time my colleagues will be iterating on a PR so commits of “fuck, that didn’t work, maybe this” are common.
I like meaningful commit messages. IMO “fixed the thing” is never good enough. I want to know your intent when I’m doing a blame in 18 months time. However, I don’t expect anyone’s in progress work to be good before it hits main. You don’t want those comments in the final merge, but a squash or rebase is an easy way to rectify that.
Merge requests should be rather small to make it easier to review.
With this I wholeheartedly agree
if your work warrants multiple commits, then it probably also warrants multiple merge requests.
With this not so much, but if you keep your merge requests so small, squashing them is no big deal, that’s a good counterexample for my previous point.
another good thing is that when we decide to release, we can easily look through the commit history for a change log. No more sifting through minor fixes commits.
That still requires you to write meaningful messages, just a bit rarer. We do have trouble with change logs, but we had exact same problems when people squashed left and right. Maybe squashing helps self-discipline, though, I haven’t thought about it that way
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”.
Often I commit because I have to jump to another branch, so I want to save my progress. This means I can be in the middle of something, so I write a trash message.
All those messages will disappear anyway after the merge request, because we use a squash policy. I can spend more time thinking of a more proper commit message when writing the merge request.
Isnt that what stash is for?
I don’t like stash for this purpose. What if I have to jump to a different branch a second time? Should I stash again?
It can be difficult to know which stash belongs to which branch. Nah, I rather just commit so I don’t need to bother with that confusion.
I agree that stash gets lost easier than a branch, but
you know, stash also has a message to it, and afaik it remembers what branch you were on when stashed
How about
WIP: <description of what you wanted but did not achieve yet>?git worktreecould become your new friend then :)I’m aware of that option. I haven’t bothered to learn it because this is a perfectly good system for me.
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
I think squashing is great and I would never want to go back. It helps ensuring:
And IMO, if your work warrants multiple commits, then it probably also warrants multiple merge requests. Merge requests should be rather small to make it easier to review.
Edit: another good thing is that when we decide to release, we can easily look through the commit history for a change log. No more sifting through minor fixes commits.
git rebasetrumps all of the things you mentioned…Anti Commercial-AI license
Git rebase can be hard to understand for many. Not everyone has the blessing of being in a team of Git gurus.
It’s more about the tooling. IDEs make it really simple.
Also people get scared when they hear it because of utterances like yours. I’m dumb af. Git rebase for your use cases can be renamed to “git edit-history $fromCommit”. Nothing special about it.
Anti Commercial-AI license
I agree with most of these but there’s another missing benefit. A lot of the time my colleagues will be iterating on a PR so commits of “fuck, that didn’t work, maybe this” are common.
I like meaningful commit messages. IMO “fixed the thing” is never good enough. I want to know your intent when I’m doing a blame in 18 months time. However, I don’t expect anyone’s in progress work to be good before it hits main. You don’t want those comments in the final merge, but a squash or rebase is an easy way to rectify that.
With this I wholeheartedly agree
With this not so much, but if you keep your merge requests so small, squashing them is no big deal, that’s a good counterexample for my previous point.
That still requires you to write meaningful messages, just a bit rarer. We do have trouble with change logs, but we had exact same problems when people squashed left and right. Maybe squashing helps self-discipline, though, I haven’t thought about it that way