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.
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".
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?
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.
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).
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.
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?