You could try unconventional commits. 
9 Likes
I know but I’m old, but so are you so maybe I should 
Although despite my age I’ve never used any other VCS than git, so checkout still makes sense to me, and using switch means I have to use a different command for a branch or sha so meh. Though I do most of my git stuff in vim with fugitive and branch switching with cough twiggy cough anyway.
The phoenix team is lucky to get a descriptive commit out of me. Gary is the MVP of commits in this regard. Conventional commit stuff seems fine, and I would have no issue following it on a team if mandated. Don’t overthink it 
12 Likes
Nice and short messages that are easy to scan still constitute “descriptive” to me. Makes me actually want to read the log.
I used to work with a guy who would do:
$ git commit -am "Update ruby, update several gems, fix CSS \
for product page, add user locking feature, bump rails minor version, \
fix pagination bug, and more!"
Sadly I’m under-exaggerating, I just can’t think up that much random stuff. It’s probably clear we didn’t have a proper project manager 
I ended up changing the accepted answer to better fit the original question, but I really want to thank you all for sharing your perspectives.
This turned out to be more of a discussion than a specific question, and I’ve learned a lot from the different angles you brought up.
Thanks again to everyone who contributed!
2 Likes
My advice:
- Use it if you like it and you find it helpful. If it’s already something you do without thinking about it, go for it. That being said, as soon as you have other contributors, I’m willing to bet that they’ll be using the prefixes wrong, and/or combining
chores,docs, andfeatchanges in the same commits. - Don’t sweat what Phoenix does or doesn’t do.
I personally don’t like it and wouldn’t use it, but I do appreciate anything that makes devs more mindful of what it is that they’re commiting.
You’ve got it backwards! git switch is considered harmful, use git checkout for everything.
Harmful? How is that?
Yes, git checkout can be used do lots of things, given you know all the possible ways to invoke it. git switch and git restore were added later, each providing some of the functionality of git checkout, and each having a simpler interface than git checkout. I cannot imagine why git switch would be considered harmful.
3 Likes
btw can’t see that image. 
3 Likes
I am not even seeing the word “harmful” in the article you linked so not sure what idea you had for posting it.
I mean OK, I guess I can use ed for everything and not need nvim but… 
GIT has undeniable DX / UX baggage, I am glad they are gradually addressing it.
2 Likes
It was a joke, I just prefer checkout.
I figured since the article reads like someone who started using git after swtich and friends were introduced. If that’s the case that’s interesting that someone would see checkout-for-everything as a positive. I do prefer it myself but only because that’s the way I learned and feel zero pain, but you can’t deny this classic!
I figured since the article reads like someone who started using git after
swtichand friends were introduced.
Nope, started using git way before switch was added.
It’s not just that I think switch is unnecessary since you can do everything it does with checkout, it’s more that I usually see people who use switch have a mental model with big gaps around not only checking the repo at a specific commit or tag, but also checking out files (or parts of files!) from other branches, tags, or commits.
1 Like
I am used to checkout and use it where necessary. Still I generally prefer switch for simply switching to other states of the repo.
It offers less surface for footguns, and by making --detach explicit, I know when I switch to a tag instead of a branch.
2 Likes
Oh it’s YOUR article, lol. Fair enough!
Ah sorry, missed the joke. Also missed that it’s your site and YouTube video
I think the important thing when writing a commit message is to match the style of the project. Phoenix doesn’t use conventional commits, so when I’m contributing there, neither do I.
Personally, I prefer it when my commits aren’t squashed when contributing to any project, because I find it easier for bisecting, but again, a consistent format in the project is desirable, so if the maintainers decide they prefer squashing, I am happy to go with it.
4 Likes
I thought I’d pasted the image, but Safari pulled a swiftie on me and inserted a link - not sure why it wouldn’t show though. I repasted…
I don’t squash well formed commit histories, but I do squash messy commits. I won’t waste time w/ OSS contributions asking people to fix their commits as you never know if they are coming back, so if it’s not up to snuff I squash it. But I think it is important to preserve the commits of those that took their time to make them good.
Ultimately I think any format that can make a commit log useful is a good idea, and conventional commits just happens to be the main one that I know of. But I’ve been thinking a lot about the #hashtag style that I mentioned above, or maybe a property list style, i.e
a nice message
type: fix
breaking_change: true
Lets you get the benefits of conventional commits but without the drawbacks people don’t like. Someone make a PR to git_ops please 
2 Likes
