Just use {JIRA Reference} - {JIRA title} and get on with your life.
The irony of this comment being that managing JIRA tickets is probably the absolute biggest time-sink of any organization that uses it.
Commit messages are not titles (2015)
11–20 of 58 posts
Re: Commit messages are not titles (2015)
#12Most commit messages look like this:
#1234 fixed the fucking fooinater that wouldn't frobulate.
Re: Commit messages are not titles (2015)
#13Commit messages are whatever an individual, community, or organization decides they should be. Debating beyond that is like debating tabs vs spaces. It doesn't matter as long as everyone you're working with is on the same page.
Seriously, in an interview I was asked about some misc code formatting preferences.
At home I use whatever prettier decides.
At work I just want to do what everyone else is doing so that we are on the same page. Maybe it is weird or something, I really don't care. More important we all work together.
Re: Commit messages are not titles (2015)
#14Just use {JIRA Reference} - {JIRA title} and get on with your life.
The irony of this comment being that managing JIRA tickets is probably the absolute biggest time-sink of any organization that uses it.
Thankfully (and also regrettably) in the org I work in now we don't have a pr standard yet... But we do use jira some of our people commit with just the bug prefix and number and not at least the title.. I really don't want to have to go paste that into the jira URL (usually more than one) to see if what you think is the issue is really the issue... Having at least the description for what you fixed helps...
Maybe it's time to dust off the "go to hell hat" and start demanding more info from the submitter...
Re: Commit messages are not titles (2015)
#15> If the first line of a commit message is a title, it changes the way you write it. It becomes just some text to introduce some more text, without any stress on the information density . I agree with the author that commit messages should optimize for information density. However the example they provide does a poor job of this: > This is a smart synopsis, as information dense as possible. "This is a" is the type of…
> I led an initiative at my current company to enforce all commit messages start with an imperative verb and be less than 72 characters.
You are truly doing god’s work :). I’ve led a similar initiative and same outcome, some love, but those who don’t, really hate it.
Re: Commit messages are not titles (2015)
#16> If the first line of a commit message is a title, it changes the way you write it. It becomes just some text to introduce some more text, without any stress on the information density . I agree with the author that commit messages should optimize for information density. However the example they provide does a poor job of this: > This is a smart synopsis, as information dense as possible. "This is a" is the type of…
I agree with your idea but I would take it further. If possible I think the commit message is more concise if it can actually refer to the resulting action that is the result of the change to the code, unless the primary result of the commit is to refactor or clean up code formatting, etc. This way we avoid one more level of indirection to indicate that we edited code to accomplish something, since that is always the case.
Link to login from home screen Enforce standard for PR titles
For refactoring, applying linting changes, or general formatting, I do prefer a prefix to indicate that it is not intended to change behavior. Something that is consistent for a project is good such as "Refactor:" or "Reformat:" or "Lint:" as a prefix to make it easy to spot these in the history is good.
I often see message such as:
Implemented new framework to... Edited 3 files...
Then someone will edit it to be imperative and it reads:
Implement new framework to... Edit 3 files...
Which is not really any better. They were past tense indicative because they described the actions of the programmer which are in the past. Writing from the imperative is not just better because it is more concise in english (shorter verbs) but because it is the natural way to describe what will happen in the program when the commit is merged.
Re: Commit messages are not titles (2015)
#17Just use {JIRA Reference} - {JIRA title} and get on with your life.
The irony of this comment being that managing JIRA tickets is probably the absolute biggest time-sink of any organization that uses it.
The complexity context has to end up somewhere (or nowhere). JIRA is a superior tool in comparison to commit message text.
Re: Commit messages are not titles (2015)
#18> If the first line of a commit message is a title, it changes the way you write it. It becomes just some text to introduce some more text, without any stress on the information density . I agree with the author that commit messages should optimize for information density. However the example they provide does a poor job of this: > This is a smart synopsis, as information dense as possible. "This is a" is the type of…
I’m jealous that your environment is competent enough that commit messages are actually worth the time to fix.
Re: Commit messages are not titles (2015)
#19Most commit messages look like this: #1234 fixed the fucking fooinater that wouldn't frobulate. Thank god for the hash ticket number linking standard. Unless you are working on the kernel, your context and discussions and notes are in the bugtracker, so there's no very good reason to write an essay in the commit log.
Until you switch bug trackers and the import process subtly mangles that link, and then you switch trackers a few years later and all hope is lost, and then five years after that you hire someone to fix all the bugs that you've been accumulating and they can't tell any of the reasoning behind anything you've done.
Are you always going to be on Jira? On Github? When people fork your project are they expected to clone your issues as well? When you migrate to another system are all your issue references still going to line up correctly? Did you even think to check?
Please continue to include the ticket reference. But also put some context in your commit message because that's what it's there for.
This is the same reason that even if you use a fancy documentation site, it should be generated from files in the repo.
Re: Commit messages are not titles (2015)
#20Trying to impose "one way" to write commit messages is silly at best.
At work I follow whatever convention the team I'm on agrees with.
For my projects I use commit messages as a way to "tag" changes, more than to explain the changes using prose. That way it's very easy for me to search for changes in the codebase.
eg. #event-loop #fix #multiple-dispatch #repeated-message (remove the # and you get the idea)