3 ms·

I guess it depends on the context in which you are seeing the message. For me, the most likely context is through blame or similar - I am looking at some code,

I guess it depends on the context in which you are seeing the message. For me, the most likely context is through blame or similar - I am looking at some code, and trying to understand its history. I see who changed it, when - and their commit message. In which case, only the intent is useful - I already likely know what the change does. The "what it does" form is more useful if for some reason you're scanning commits trying to find the one that introduced some particular change. But that's not a use case I ever encounter.

citrin_ru 3y ago
> The "what it does" form is more useful if for some reason you're scanning commits trying to find the one that introduced some particular change. But that's not a use case I ever encounter. There are at least two use cases where I find it useful: 1. To review (recent) changes when you have no time to read full diffs but may hope that git commit messages will give a good idea what was changed since the previous review. There are many repos I follow and reading logs takes less time than diffs. 2. To find out when some change was made for which I know keywords to look in a message but not the code (and then I can check a diff to see the code). Why is indeed very important but a good commit messages can have booth: a short summary for what was changed and why.
- stevage 3y ago
  Yeah those use cases make sense!
lapcat 3y ago
> The "what it does" form is more useful if for some reason you're scanning commits trying to find the one that introduced some particular change. But that's not a use case I ever encounter. I've encountered it many times.
- stevage 3y ago
  I didn't mean to imply that others wouldn't.
csnover 3y ago
What you are describing basically matches my experience. Whether I’m doing a blame or a code review, if I’m reading commit messages, I’m doing it to understand why some thing is the way it is. Reciting what changed in 70 characters instead of saying why it changed doesn’t feel like it helps me much. For the case of trying to find a change, I’d personally just run `git log -G` or `git log <file glob>` depending on what I’m looking for. I suppose one must know that these commands exist, though, so maybe that’s part of it.

citrin_ru 3y ago

> The "what it does" form is more useful if for some reason you're scanning commits trying to find the one that introduced some particular change. But that's not a use case I ever encounter. There are at least two use cases where I find it useful: 1. To review (recent) changes when you have no time to read full diffs but may hope that git commit messages will give a good idea what was changed since the previous review. There are many repos I follow and reading logs takes less time than diffs. 2. To find out when some change was made for which I know keywords to look in a message but not the code (and then I can check a diff to see the code). Why is indeed very important but a good commit messages can have booth: a short summary for what was changed and why.

stevage 3y ago
Yeah those use cases make sense!

lapcat 3y ago

stevage 3y ago
I didn't mean to imply that others wouldn't.

csnover 3y ago

What you are describing basically matches my experience. Whether I’m doing a blame or a code review, if I’m reading commit messages, I’m doing it to understand why some thing is the way it is. Reciting what changed in 70 characters instead of saying why it changed doesn’t feel like it helps me much. For the case of trying to find a change, I’d personally just run `git log -G` or `git log <file glob>` depending on what I’m looking for. I suppose one must know that these commands exist, though, so maybe that’s part of it.