lmika
lmika

So, this is how my morning went.

A drawing of a Git commit tree showing a successful merge of Y with a green CI/CD run, a few commits of me making changes to a branch over the course of 2 days, then eight commits with a few minutes between each one with each one having a red CI/CD run. The commit messages suggest that each one was an attempt to fix the CI/CD problems of the previous one.

Apologies to my reviewers for all the notification emails they’re receiving during this battle with the CI/CD build.

|
Embed
Progress spinner
lmika
lmika

@lmika It took 14 commits, but the battle's finally won. Now to hide evidence of the struggle by squashing all these into a single commit. 🥸

Just kidding: merging the MR will squash them anyway.

|
Embed
Progress spinner
V_
V_

@lmika out of curiosity, du you generally squash all your mr down to a single commit? I tried this for a while, but when I ever need to search a bug if find it quite unhandy to have lost the single commits inbetween from developing the feature. But having a single linear history on main would be so nice. Compared to the mess I usually get. I also sometimes wondered whether it is just a sign of my features being too big.

|
Embed
Progress spinner
In reply to
lmika
lmika

@V_ Yes, I tend to squash my commits before I raise a MR. I was once on a team that strongly encouraged us to do so, so that once we merged our history would be relatively tidy. We weren't squashing when we merged back then though, unlike the team I'm on today. So I probably don't need to squash, but there are some benefits from doing so, like when rebasing recent changes from main, I only have to resolve conflicts on one commit. Other than that, it's just habit.

|
Embed
Progress spinner