4 ms·

> If your commit message isn't sufficient enough to explain the purpose of the commit (ticket numbers, explanation, etc), it doesn't get approved. I'm glad thi

by zck 10y ago

> If your commit message isn't sufficient enough to explain the purpose of the commit (ticket numbers, explanation, etc), it doesn't get approved. I'm glad this is the case where you work and develop. I have never worked at a company where this is the case. I'm also not perfect about commit messages in my personal code. The codebase I'm currently working on has recent commits with description "review", "add addressDto" and "post rebase fix". > >which I think a mercurial-style branch name answers. > I find that extremely suspect. Ok. If I see "add addressDto" as a part of the branch "google-geocoding", that tells me the context. If I see it as part of "refactor-to-use-hibernate", that also tells me something useful.

justinlaster 10y ago
>The codebase I'm currently working on has recent commits with description "review", "add addressDto" and "post rebase fix". I guess what I don't get, is that if you have people doing commit messages like that, how can you possibly expect them to appropriately name a branch which most likely stores far less characters.
- zck 10y ago
  Because you're less in the nitty-gritty when naming a branch, so you're more likely to name it with something referencing the large feature you're working on.
- aidenn0 10y ago
  Far too often the commit message says "what" while the branch name says "why." Just recently I had to triage a recently discovered bug whose symptoms disappeared about 4 years ago to determine if the bug was fixed or just masked. This was code that I was completely unfamiliar with because the other engineers that might have looked at it were otherwise indisposed working on things that were known for sure to be issues. The "what" told me the specific change that masked the bug and the "why" informed me of the feature that this supported. That allowed me to generate a new test-case that showed up in the current version. Without both pieces of information I would likely have had to spend a couple of hours inspecting code changes to do the same.
  - justinlaster 10y ago
    If you can't trust your developers to write acceptable commit messages, why are you trusting them to write code?

by zck 10y ago

justinlaster 10y ago

>The codebase I'm currently working on has recent commits with description "review", "add addressDto" and "post rebase fix". I guess what I don't get, is that if you have people doing commit messages like that, how can you possibly expect them to appropriately name a branch which most likely stores far less characters.

zck 10y ago
Because you're less in the nitty-gritty when naming a branch, so you're more likely to name it with something referencing the large feature you're working on.
aidenn0 10y ago
Far too often the commit message says "what" while the branch name says "why." Just recently I had to triage a recently discovered bug whose symptoms disappeared about 4 years ago to determine if the bug was fixed or just masked. This was code that I was completely unfamiliar with because the other engineers that might have looked at it were otherwise indisposed working on things that were known for sure to be issues. The "what" told me the specific change that masked the bug and the "why" informed me of the feature that this supported. That allowed me to generate a new test-case that showed up in the current version. Without both pieces of information I would likely have had to spend a couple of hours inspecting code changes to do the same.
- justinlaster 10y ago
  If you can't trust your developers to write acceptable commit messages, why are you trusting them to write code?