3 ms·

"A good commit consists of multiple elements, but at a minimum, it should have a well-crafted commit message. " I'm not sure I accept this premise. Just a few w

"A good commit consists of multiple elements, but at a minimum, it should have a well-crafted commit message. " I'm not sure I accept this premise. Just a few words is all that is needed. Anymore and it becomes this OCD novel you are writing that doesn't actually help the code base later. Git log -p is where you really look to see what the commit did, not a well crafted message.

artursapek 2y ago
commit messages can be useful sometimes to explain the context of a change, but I agree if the code doesn't speak for itself then adding a comment above it is probably a better, more permanent solution.
- stagalooo 2y ago
  A code comment can tell you why the code is the way it is, but it shouldn’t tell you why it changed. That’s what commit messages and/or PR descriptions are for.
  - artursapek 2y ago
    I meant "long commit messages"* in my OP
floodle 2y ago
The diff will tell you what's changed, but it doesn't tell you the "why" of the change. A project should store that information somewhere; whether it's in pull request descriptions, issues/tickets, or the commit message, which is a perfectly reasonable choice.
johnisgood 2y ago
I omit very obvious stuff from the git commit if it is visible in a diff, for example if I change "a" to "b", my commit message is not going to be "Changed a to b", but something more general, not too specific, that is what the diff or source code is for. And as someone said, I often include the "why".
barbazoo 2y ago
> Just a few words is all that is needed. But then this wouldn’t be a good application for a LLM so clearly that cannot be /s
keybored 2y ago
A well-crafted commit can have a few words or five paragraphs. A few words will never be enough for a non-obvious change. Some people might then say “use code comments”. But those inline comments won’t work when you have five years of source code change and those three lines deserve a cumulative seven comments.

artursapek 2y ago

commit messages can be useful sometimes to explain the context of a change, but I agree if the code doesn't speak for itself then adding a comment above it is probably a better, more permanent solution.

stagalooo 2y ago
A code comment can tell you why the code is the way it is, but it shouldn’t tell you why it changed. That’s what commit messages and/or PR descriptions are for.
- artursapek 2y ago
  I meant "long commit messages"* in my OP

floodle 2y ago

The diff will tell you what's changed, but it doesn't tell you the "why" of the change. A project should store that information somewhere; whether it's in pull request descriptions, issues/tickets, or the commit message, which is a perfectly reasonable choice.

johnisgood 2y ago

I omit very obvious stuff from the git commit if it is visible in a diff, for example if I change "a" to "b", my commit message is not going to be "Changed a to b", but something more general, not too specific, that is what the diff or source code is for. And as someone said, I often include the "why".

barbazoo 2y ago

> Just a few words is all that is needed. But then this wouldn’t be a good application for a LLM so clearly that cannot be /s

keybored 2y ago

A well-crafted commit can have a few words or five paragraphs. A few words will never be enough for a non-obvious change. Some people might then say “use code comments”. But those inline comments won’t work when you have five years of source code change and those three lines deserve a cumulative seven comments.