151–160 of 185 posts
I rarely pay much attention to git commit messages. I would very much rather look at the diffs and see where/what it changed.
>Capitalize the subject line
Does this really matter? Really?
Honestly, the best guidance is just "put more than 2 seconds effort into your commits". No one really believes "More code" is a good commit message, it's just laziness. So yeah, put a little effort in, it's literally one of the few parts of your work that will remain once you are gone. Most code I've worked on gets replaced/updated/modified after I'm done working on it - but the one thing that I know will stay is the…
In practice, there often is not a very strict process around commits, so specific advice is often not very useful either.
I have only been using git for a few years. subversion was popular for a long time. I rarely pay much attention to git commit messages. I would very much rather look at the diffs and see where/what it changed. >Capitalize the subject line Does this really matter? Really?
Earlier quoted context omitted.
I built a full pipeline around this. Basically allowed for a paved road for devs to automatically semantically version and deploy application and module artifacts for npm with semantic release by spinning up a repo with some boilerplate generators I made available to the team. Since then I've been obsessed with the conventional commit format everywhere for my own projects. Even if the commits aren't parsed for versio…
> I was constantly surprised by how many questions I got about something as seemingly simple as the conventional commit format from a crowd of enginerds. I'm not. Writing code and writing git commit messages take entirely different types of thinking. With code you are having to think logically and problem solve to tell the computer what to do. Git messages are more analogous to writing a term paper (though shorter).…
https://github.com/synek/git-plan
One feature I wanted to add was for it to parse your source code for comments with a specific format (e.g. `# git-plan feat xyz` or `# git-plan fix xyz`) and then stitch all the hunks together into commits for you. So all you'd have to do is comment your code and then run `git plan commit` and it would generate commits for you to confirm with y/n.
I built a prototype of that here:
https://github.com/synek/codeline
I haven't worked these for a while unfortunately :(
What do people think of this line? > Use the imperative mood in the subject line The only rationales I've seen for using imperative ("fix bug") over the indicative ("fixed bug") are that it's what git does by default anyways. Is it really that big of a deal to use the indicative sometimes and imperative other times? For what it's worth, I always write commit messages in the imperative, out of habit. When others write…
So for me, it's not about the commit message itself, but the communication style says something about the developer and how I best approach them.
My take on this requirement is that it helps developers let go of their attachment to the code they've written.
We also have a rule to prepend every commit message with its issue number in our issue tracker (we don't use GitHub). That way in Git Blame/Log you can always quickly find where the change came from and why - the issue tracker usually has more detailed information.
That place used JIRA where the typical ticket ID was around 10 characters. That wasted a lot of prime real estate, e.g. in my email inbox, in history views (tig, gitk, and so on).
I also don't see the claimed benefit for git blame. In a real code base with significant history, it happens often enough that the first blame is an unrelated refactoring and you need to dig deeper. Therefore, I find that best practice is to look at the blamed commit first instead of the ticket. That gives you the full commit message, which can still contain a reference to an issue.
Putting footer lines like "Fixes: " into commit messages works much better. It's just as easily visible in git log etc. and doesn't waste space.
Mine is "[JIRA_TICKET] Add something" It's simple and worked well for us so far. Less rules, more information, and developers are free to use their words to express intention of changes instead of nonsense (feat, fix,....)
Point being, in a few years all your [external references] will be useless. Can your commit messages explain the commit context on their own?
Earlier quoted context omitted.
Honest question, do you really expect your history to be meaningful long-term? Or are you simply taking the approach that the commit message is meaningless and a developer instead use GitHub search to find a PR relevant to a change they're investigating. For example, I pulled up one of your projects and the history ( https://github.com/transitive-bullshit/kwote/commits/main ) is less than meaningless, compared to i.e…
Fastapi use gitmoji [0], this is well-documented and structured. [0] -- https://gitmoji.dev/
You mean the entire developer's thought process behind a change will be represented by a single 12x16 picture? Even hieroglyphs were more expressive than that.
I'm a heretic who prefers information in the PR. That's where the long-form back and forth arguments happen over the edge conditions. Periodically a few days after a PR has been merged I'll have a discussion with someone and realize some context was never captured, so I'll just add it at the bottom of the closed+merged PR for posterity. Yeah that means all the important information is in GH but if you migrate to GitL…
I subscribe to this and: > "The Not Rocket Science Rule Of Software Engineering: automatically maintain a repository of code that always passes all the tests" https://graydon2.dreamwidth.org/1597.html Intermediate commits to produce a pretty history while not passing the tests reduce their usefulness to about zero.
I also like the approach where tests are performed in a temporary integration branch, then the main branch gets fast-forwarded to the tip of that integration branch only after the tests pass.
But the idea that intermediate commits must always pass tests forces you into some nasty contortions.
Say that you have to move files around, after which the tests fail, and then make a few minor changes to accommodate the new locations so the tests pass once agian. If you combine those two operations into a single step, troubleshooting that commit is a pain because the diff is gigantic.
For this reason, I prefer a less strict rule: all PRs get a merge commit and merge commits must always pass tests.
Interesting topic. From my experience Headline + Bullet Points are far quicker to convey useful information, in a form that is terse yet easy to read. For example: ---------------- improve Buffer Cache Management & logging - change 'tryDrop()' to skip immediately, if lock unavailable - move BufferCache logging to a separate logger - attach BufferTrim.Unsuccessful -> Preemptive Flush of oldest buffers ----------------…
I don't really have a problem with bullet points, conveying relevant information is after all the most important thing the message should do, but if that example is an actual one then it would raise some flags during review. Mainly because it's not super readable (mix of styles, super terse requires extra interpreting) but also because it mostly explains what has changed (most often unneeded information, as that shou…
Ideally, commit messages should at least briefly explain what was changed (e.g., Add feature X, Fix bug Y) in addition to why it was done. When people look at git log output, they won't always show the associated diff for each log message. Also, when running git blame, they'll see the commit id and title, but not the entire change.
That doesn't mean that one can't run other commands to see the associated diff, or even getting the overall branch diff from the commit ids recorded in the merge commit, but having that what was done in the commit message allows one get an understanding before looking into it in more detail.