4 ms·

I don't really have a problem with bullet points, conveying relevant information is after all the most important thing the message should do, but if that exampl

by stinos 4y ago

I don't really have a problem with bullet points, conveying relevant information is after all the most important thing the message should do, but if that example is an actual one then it would raise some flags during review. Mainly because it's not super readable (mix of styles, super terse requires extra interpreting) but also because it mostly explains what has changed (most often unneeded information, as that should be clear from the diff) and not really why it is done that way (ok, the code might have comments, but still I expect the message to explain that). In my experience, using bullet points like this is correlated with this style of messages which just list 'I did x, y, and z' whereas a more narrative style, which can still go in bullet points, is correlated with easily digestable messages explaining properly the reasons for changes. Anecdotal of course.

u801e 4y ago
> it mostly explains what has changed (most often unneeded information, as that should be clear from the diff) and not really why it is done that way Ideally, commit messages should at least briefly explain what was changed (e.g., Add feature X, Fix bug Y) in addition to why it was done. When people look at git log output, they won't always show the associated diff for each log message. Also, when running git blame, they'll see the commit id and title, but not the entire change. That doesn't mean that one can't run other commands to see the associated diff, or even getting the overall branch diff from the commit ids recorded in the merge commit, but having that what was done in the commit message allows one get an understanding before looking into it in more detail.
- stinos 4y ago
  Ideally, commit messages should at least briefly explain what was changed Yes, sorry didn't mention it explicitly, but that's normally what the first line of the commit message is for.

by stinos 4y ago

u801e 4y ago

> it mostly explains what has changed (most often unneeded information, as that should be clear from the diff) and not really why it is done that way Ideally, commit messages should at least briefly explain what was changed (e.g., Add feature X, Fix bug Y) in addition to why it was done. When people look at git log output, they won't always show the associated diff for each log message. Also, when running git blame, they'll see the commit id and title, but not the entire change. That doesn't mean that one can't run other commands to see the associated diff, or even getting the overall branch diff from the commit ids recorded in the merge commit, but having that what was done in the commit message allows one get an understanding before looking into it in more detail.

stinos 4y ago
Ideally, commit messages should at least briefly explain what was changed Yes, sorry didn't mention it explicitly, but that's normally what the first line of the commit message is for.