Hi everyone,
I noticed that the Phoenix framework doesn’t use Conventional Commit prefixes like feat:, fix:, or docs: in its commit messages.
Is there a reason this style isn’t common in Elixir projects? Would using it be helpful or unnecessary for open source libraries?
I’m deciding whether to adopt it in my own project—curious to hear your thoughts.
Thanks! 
Can’t speak for phx - but i’ve been using conventional commits for my open source stuff, i put it down to a matter of style and preference.
I particularly like it for calculating SemVers and the uniform feel of changelogs.
If you’re exploring them, I’d have a look at something like GitHub - cocogitto/cocogitto: The Conventional Commits toolbox , which makes conventional commits trivial to use.
Quite a few projects do use Conventional Commits, notably the Ash suite of libs.
A good library for implementing Conventional Commits in Elixir is GitOps. It handles versioning based on commit types, tagging, managing changelogs, updating the latest version number in documentation e.g. README.md, etc.
Can’t speak for the phoenix project.
I tend to use them in my own projects. I find them a helpful signal, but not a requirement. To me, it is a sign that the project is detail-oriented.
In my repo I use a workflow to enforce this style:
Personally I greatly dislike the “conventional commit” style and prefer descriptive, sentence case commits with additional context. I’ll rewrite the message for pull requests that start with “feat:” to match the style of the repository.
When it comes to the changelog, I group bugs and enhancements, but do it when I’m writing the changelog. The messages usually get expanded into something more descriptive as well.
I also prefer sentence case in the imperative tense matching git’s auto-generated merge commits, ie, “Merge a into b”. There’s no period because, no matter what anyone tells you, it’s a subject line that hopefully has a body 
Also, if you happen to be vehemently against squashing PRs (although it does make sense in many libraries) then conventional commits feel like they’d be an annoyance.
Ultimately it doesn’t matter so long as it’s consistent. Of course, multiple companies I’ve worked for don’t even care about consistency so I’ve largely stopped stressing about it and sometimes just do git commit -am "changes".
Apologies for the rant 
Any standard is probably better than no standard.
I’d like to make git_ops support a tag type syntax for commits in addition to conventional commits.
improvement: make the frobnicator work better
some more details
could easily be
make the frobnicator work better
#improvement
#breaking-change
Or other potential formats. It would be a really simple change to our parser. The point for me is just being able to get that info from the commits, not the actual format. It would probably be trivial to implement.
In case anyone is interested in the features (automatic changelog generation and version numbering) but don’t want to use conventional commits, PRs welcome to git_ops 
I might even switch to something like that for the Ash project at some point.
We also just added logic to use the GitHub API to include links to the user who contributed a change where possible as part of generating a changelog etc. Conventional commits is just an implementation detail at the moment.
I remember you introducing this but I assume I wrote it off due to the conventional commit dependency. It’s cool that you’re considering an alternative as this looks really useful. I’m still not 100% sure I’d use it but hypothetically would you be open to a PR for making it available as an escript? None of my (active) open source projects are Elixir. Or is this just meant for Elixir projects (looking through the README it doesn’t seem that way). EDIT: oh right the config would maybr have to support JSON or toml or something in this case?
Yes, happy to use json or toml config to support being an escript or some other type of thing
Thanks so much for all the thoughtful and detailed replies! 
I really appreciate the mentions of GitOps and the lint workflow.
As I read the arguments for sentence case in the imperative tense, I now find it more logical than the sometimes redundant prefixes.
For now, I tend to stick with sentence case in the imperative tense to keep things consistent in my current library.
Thanks again! 
LOL, thanks for the checkmark despite my getting a bit ranty 
Of course any team should do whatever they see fit, but I only relatively recently (a couple of years ago) realized that the squashing practice is actually extremely prevalent. git blame is actually an incredibly useful tool on a codebase where the history is intact as it’s effectively an immutable comment that can’t get out of date. Of course it only helps if everyone commits often, and it’s especially helpful if your teammates have good local rebase fu. Unfortunately, I’ve several times seen people online wearing their lack of anything other than the most basic of git knowledge as a badge of honour, so what can you do. Things may not have been this way if Mercurial had won with its objectively better UX, so I do understand, but I’ll continue to shake my fist at the clouds
A bit weird comment from you here IMO. Squashing is a necessary reality for many commercial projects with movements from different people every day. Rebasing sounds good in theory until you see three PRs worth of commits splattered and interspersed in the linear history – after the PRs are done. It’s just confusing. Maybe it’s being more knowledgeable but does not help with readability at all. 
Furthermore, atomic commits are very nice and I approve of them but in a commercial setting they are very often a luxury. So if you can’t have atomic commits then squashed PRs are the second best thing IMO.
Now one thing I don’t like and will never like is how one is forced to go to their (web-based) GIT hosting to drill down on a PR if (and when) needed once git blame points the finger at a squashed PR commit. This should have been a feature of GIT.
You can easily have that with git – by not squashing commits, but merging using merge commits.
In my opinion the best way is to rebase off main then force a merge commit with git merge --no-ff (I believe it can be done in one go with git rebase --merge --no-ff but it’s been a while). This way everything is together and if you write a meaningful message for the merge commit (as opposed to accepting the default) then you can get the “squashed” history with git log --merges. I do actually think github has some blame here as there is no way to do any of this in their UI (there might be a way to filter by merge commits by passing URL params, I’m unsure).
I’ll openly admit that I haven’t done that in so long that I’ve forgotten how does it look in the repo history… 
I wonder if this is the same that @LostKobrakai said could be done, hmm.
Yes, sorry, I was sorta both responding to you and expanding on what LKK said but was not very clear about that. So long as you make sure there is always a merge commit you get the best of both worlds. Though I will reiterate that I think it’s best to do the rebase merge so all the commits for a particular feature are grouped together as I agree that that trying to a mangled tree of git history is a terrible experience. A rebased no-ff merge (lordy do I dislike git terminology) ensures you always get a linear history.
I see that I have forgotten a few things about git which is sad but also normal. Now I have to go look for a visual explanation of what exactly “a rebased no-fast-forward merge” is.
Ideally I would like change-set-kind-of-things where each PR is not squashed; you can still expand it of sorts, like a directory with files. And we can have fully recursive history that way. I have not researched VC systems in a long time, in my mind GIT has won long time ago. But… we also have jujutsu which I liked a lot but just not willing to invest the time and energy to replace git with something that’s one layer above it just yet.
That’s what I’m describing essentially gets you.
And yes… git terminology 
First off, I was wrong about git rebase --merge --no-ff—there may be a shortcut command but I forget. The long way is:
git checkout feature
git rebase main
git checkout main
git merge --no-ff feature -m "My cool feature"
This creates a merge commit called “My cool feature” with all the commits that got it there grouped below it. You can git show the merge commit to see the diff for the full feature and when you git blame a file, you get the message for the specific commit that introduced it as opposed to a generic message for a feature that took a few days to complete.
Now, if your team is somehow amazing at always submitting bite-sized PRs that’s another story. I have yet to work anywhere that manages to do this.
PS, yes jujutsu looks cool but I still haven’t invested any time. I know it’s currently built of off git but I believe the idea is to eventually drop it as a dependency?
I have bookmarked this comment, FYI.
btw you can replace this:
git checkout feature
with this:
git switch feature
It has been a part of GIT for a while now and I am getting used to it and I like it. I am really tired of GIT’s quirky terminology.
© Copyright Elixir Forum | Terms | Privacy & Cookies
