3 ms·
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/
by flafla2 7y ago
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.
- coldtea 7y ago>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.