Why should a message subject not end with a period?
Commit messages are not titles (2015)
51–58 of 58 posts
Re: Commit messages are not titles (2015)
#52Earlier quoted context omitted.
The irony of this comment being that managing JIRA tickets is probably the absolute biggest time-sink of any organization that uses it.
I find JIRA light weight. The trick is not to follow too many processes. Drag on tickets to your board when you start them and move then through the swim lanes. The worst cases are when people set up too much security and complex transition rules so that people are blocked by JIRA. JIRA ain't perfect though. The constant UX changes drive me nuts. At least HN still works the same way as 10 years ago, but JIRA keeps ch…
The fact that larger companies that use JIRA have to employ full time "JIRA Administrators", or worse, teams of JIRA admins, suggests that the tool is anything but lightweight.
Re: Commit messages are not titles (2015)
#53Earlier quoted context omitted.
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.
And an industrial mining dump truck with 14 ft wheels is a superior tool to a cargo bicycle. Doesn't mean it's the right tool for the job.
Re: Commit messages are not titles (2015)
#54Earlier quoted context omitted.
I find JIRA light weight. The trick is not to follow too many processes. Drag on tickets to your board when you start them and move then through the swim lanes. The worst cases are when people set up too much security and complex transition rules so that people are blocked by JIRA. JIRA ain't perfect though. The constant UX changes drive me nuts. At least HN still works the same way as 10 years ago, but JIRA keeps ch…
The fact that larger companies that use JIRA have to employ full time "JIRA Administrators", or worse, teams of JIRA admins, suggests that the tool is anything but lightweight.
Larger companies need meta-roles. That is never going away. If that "PMO" person isn't using JIRA, they are using something else, or there are even more people wasting time dealing with all this via email and shared Excel sheets.
Re: Commit messages are not titles (2015)
#55Commit 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.
That's an easy copout though. Sure, commit messages could be mandated to be "whatever an individual, community, or organization decides they should be". That doesn't mean any of those choices is optimal in absolute terms, or even optimal for the use case of the individual, community, or organization who made the decision. So it makes sense then to debate what the optimal choice (either absolute, or per use case) is,…
I think the core issue is that people consume/view Git commit messages in different ways depending on their needs. Realistically, most people today use Github/Gitlab/Sourcehut/whatever web git gui along with the Git CLI. So the old wisdom of "commit-as-subjects," which made sense when people viewed commits in email chains, is no longer always relevant. In many organizations and communities, git commit messages mirror PR titles, and in this specific context it makes a lot of sense for commit messages to be written as titles with a longer description attached. As an individual, I might use git to version a blog post I'm writing, and in this case I could use my own entirely individualized semantics for commit messages.
I don't even think there is a choice that is "optimal in absolute terms" as you claim. However, consistency within a project is absolutely key and is something we can hopefully all agree on.
Re: Commit messages are not titles (2015)
#56Earlier quoted context omitted.
That's an easy copout though. Sure, commit messages could be mandated to be "whatever an individual, community, or organization decides they should be". That doesn't mean any of those choices is optimal in absolute terms, or even optimal for the use case of the individual, community, or organization who made the decision. So it makes sense then to debate what the optimal choice (either absolute, or per use case) is,…
I think the core issue is that people consume/view Git commit messages in different ways depending on their needs. Realistically, most people today use Github/Gitlab/Sourcehut/whatever web git gui along with the Git CLI. So the old wisdom of "commit-as-subjects," which made sense when people viewed commits in email chains, is no longer always relevant. In many organizations and communities, git commit messages mirror…
>Realistically, most people today use Github/Gitlab/Sourcehut/whatever web git gui along with the Git CLI. So the old wisdom of "commit-as-subjects," which made sense when people viewed commits in email chains, is no longer always relevant.
It's not "commits as subjects", it's commits as titles. And it doesn't come from viewing the commits through email clients. It comes from needing to know what the commit contains and why was the change done. That is, from having a descriptive title for the change. This is needed whether one checks the commit in their email, on Emacs, on GitHub, or cli.
>As an individual, I might use git to version a blog post I'm writing, and in this case I could use my own entirely individualized semantics for commit messages.
Sure, that's a niche use though, not the use discussed here, which is about commit messages for programming.
Re: Commit messages are not titles (2015)
#57Earlier quoted context omitted.
I find that requiring "nice" commit messages tends to mean digging through bigger diffs to find the breaking change. If you're fine with commit messages like "fix" or "derp", then people are more willing to make each tiny change a separate commit, and then a git bisect takes you right to the specific diff that caused the problem.
Absolutely not! Submitting "derp" to code review is just disrespectful of the reviewer's time. There's a rationale for every change. The submitter knows it. The reviewer needs to know it. They can try reconstructing it from the diff, which is potentially error prone .. or you could just tell them. I'll accept "Fix ticket #1234", since that's moved the rationale elsewhere.
A PR needs a review and a written rationale, agreed, but that doesn't mean each individual commit does (indeed one usually reviews the diff as a whole, not the individual commits). Commit everything that compiles, make the PRs at a coarser granularity, then you get the best of both worlds.
Re: Commit messages are not titles (2015)
#58Earlier quoted context omitted.
If AI can write news articles these days I wonder if the actual answer is what you wrote. Build a commit parser into version control to auto-write the titles for you. All you do is write a good message. Prettier but for commit messages.
> Build a commit parser into version control to auto-write the titles for you. This is like the auto-javadoc software: if the computer can write it from information already in the code, it's a wasteful duplication of time. Use commit messages and comments for why . Especially if you chose not to do something in a more obvious way for a specific reason. You can't have "self-documenting" for code the version of code th…
The title is a duplication of effort from the message. Devs just write a good message, generate a perfect title from that and the context of the commit itself.