My commit messages have gotten extremely lazy since I start squashing all my commits down to one. I just describe the PR on the first commit message and write nonsense in all the others.
I know that if you are on the local repository where the commits were originally created they’ll remain accessible through recovery methods but AFAIK orphaned commits aren’t synced to other machines.
That’s correct. This is for work, which uses GitHub. The dangling commits remain accessible via their sha through the web ui, so I can link them in the PR description. I don’t put them in the actual commit message.
I think these are garbage collected eventually, but no idea on cadence. It’s long, anyway.
Whatever works for you, but I love writing a quality commit message. It’s like my reward for doing all that work - wrapping up the changes in a nice little summary.
Sometimes I just scroll through my commits when I’m feeling blue…
Wait, people are complaining about manor lords already? So far I like it and haven’t come across anything bothersome yet. I haven’t played a ton, but I’m getting a good village going.
If anyone thinks hiring 50 people will get them an update in a week, they’ve never worked on a group project at all, let along a comolicated one. They’ve been working on it for what, 5 years now? And it’s just gotten what is essentially a beta buukd?
These people need to chill out and let a good game slowly unfold, not take a promising start and try to speed run into the trash can.
Luckily the devs are a lot smarter than the average 11 year old.
This is what I hate about squashing. I love the fact that my crazy journey to a finished feature is there in the log for everyone to see, including myself lol. But squashing makes me feel empty when I write commit messages. Where’s the fun… Just a straight line of perfectionism. Maybe someone has a crazy but cool idea that would be worth picking. 🍒
Maybe. I do more DevOps these days, so tend to have many small changes that can’t even be tested without checking them in and running in CI. I’d have hundreds of “fix unit tests” commits alone
We squash. I’m not really interesting in your local journey to land the change. It’s sometimes useful during review, but after that it’s mostly the state of the main branch I care about. It’s what I need to bisect anyway.
I don’t like commits that are just references to issues. Copy the issue into the commit message so git blame tells you something useful. Unless it’s just closing a simple big. Then the title and issue reference are plenty.
I’ve been thinking about that when talking to my DevOps colleagues, that there’s gotta be a better way to test CI before committing. The whole change-commit-test dance would kill me if on a daily basis. So cumbersome.
programmer_humor
Oldest
This magazine is from a federated server and may be incomplete. Browse more on the original instance.