4 ms·

Git and Subversion even allowing single line “-m” commit messages was a mistake. You would see a lot better messages if they forced you to use the editor. I bet

Git and Subversion even allowing single line “-m” commit messages was a mistake. You would see a lot better messages if they forced you to use the editor. I bet a lot of programmers don’t even know you could do multi line messages and assume there is some short-ish character limit. I know I did for a long time

cozzyd 6y ago
agreed... I use -m out of laziness a lot, but every time I don't it's much better.
- _ikke_ 6y ago
  Note that you can provide -m multiple times to add multiple paragraphs to the commit message.
worldsayshi 6y ago
> lot of programmers don’t even know you could do multi line messages More like most times when people look at logs they will only have the first line visible anyway.
- benibela 6y ago
  There are probably programmers that do not know there can be more than one line even after looking at a commit with a multi line message
jimktrains2 6y ago
Just a bit, you can have multiple lines with -m, I do it frequently. You can also write single line messages in an editor, which I'm also frequently guilty of. They're orthogonal issues. Yes, however, -m does encourage people to make single line messages.
cardiffspaceman 6y ago
I feel a huge pain of resignation when I am forced to use multiple lines to describe a single commit. There is almost no audience for any line of the commit message other than the first line. As far as line length goes, any practical means of displaying the messages, like gitk or git --oneline, is unfriendly to lengthy lines. Gerrit will display all the lines of the tip commit's commit message, so one can amend that commit to create a summary of the others, but then of course the other commits are not as visible. The character limits are a real thing in git culture. One could start here, with a question posed by an apparent skeptic: https://stackoverflow.com/questions/2290016/git-commit-messages-50-72-formatting https://stackoverflow.com/questions/2290016/git-commit-messa...
- u801e 6y ago
  > There is almost no audience for any line of the commit message other than the first line. git log would definitely show the entire commit message, so I don't see why there would be almost no audience. git blame along with git show or git log -n1 would also allow you to see the rest of the commit message for a particular line in the codebase.
  - Silhouette 6y ago
    git log would definitely show the entire commit message git log could show the entire commit message, but I can't remember the last time I saw any developer whose default format wasn't a single-line one. Presumably there are some people who do prefer to see the whole message every time, and maybe that includes you, but IME that's quite rare.
    - u801e 6y ago
      One would actually have to make a change to their global git config to set the pretty setting to display oneline or add a bash alias to run git log --oneline. By default, it shows the entire message, and, in my experience, most people aren't going to change the default behavior in one specific case.
Silhouette 6y ago
Git and Subversion even allowing single line “-m” commit messages was a mistake. That's a subjective preference. Maybe for some repos it's a good idea to allow or even require longer messages, but certainly not all. For example, after seeing many different strategies for commit messages over the years, my own preference in many cases is now to permit only one-line commit messages, with a strict character limit, which include a reference to a suitable source such as a feature or bug ID where more details may be found. With git, this can be checked using a pre-commit hook. The big advantage of this is that a `git log` or similar command with a single-line format can never then hide anything important. Assuming we're talking about an established project that does have things like a bug tracker and some sort of structured project documentation set up, I have found that any time I am tempted to write a longer commit message, there is usually a better place I could record that information, and if not then maybe it wasn't that important anyway. YMMV, of course. As I said, it's a subjective preference, and no doubt there are many different ways a team might choose to use their tools.

cozzyd 6y ago

agreed... I use -m out of laziness a lot, but every time I don't it's much better.

_ikke_ 6y ago
Note that you can provide -m multiple times to add multiple paragraphs to the commit message.

worldsayshi 6y ago

> lot of programmers don’t even know you could do multi line messages More like most times when people look at logs they will only have the first line visible anyway.

benibela 6y ago
There are probably programmers that do not know there can be more than one line even after looking at a commit with a multi line message

jimktrains2 6y ago

Just a bit, you can have multiple lines with -m, I do it frequently. You can also write single line messages in an editor, which I'm also frequently guilty of. They're orthogonal issues. Yes, however, -m does encourage people to make single line messages.

cardiffspaceman 6y ago

I feel a huge pain of resignation when I am forced to use multiple lines to describe a single commit. There is almost no audience for any line of the commit message other than the first line. As far as line length goes, any practical means of displaying the messages, like gitk or git --oneline, is unfriendly to lengthy lines. Gerrit will display all the lines of the tip commit's commit message, so one can amend that commit to create a summary of the others, but then of course the other commits are not as visible. The character limits are a real thing in git culture. One could start here, with a question posed by an apparent skeptic: https://stackoverflow.com/questions/2290016/git-commit-messages-50-72-formatting https://stackoverflow.com/questions/2290016/git-commit-messa...

u801e 6y ago
> There is almost no audience for any line of the commit message other than the first line. git log would definitely show the entire commit message, so I don't see why there would be almost no audience. git blame along with git show or git log -n1 would also allow you to see the rest of the commit message for a particular line in the codebase.
- Silhouette 6y ago
  git log would definitely show the entire commit message git log could show the entire commit message, but I can't remember the last time I saw any developer whose default format wasn't a single-line one. Presumably there are some people who do prefer to see the whole message every time, and maybe that includes you, but IME that's quite rare.
  - u801e 6y ago
    One would actually have to make a change to their global git config to set the pretty setting to display oneline or add a bash alias to run git log --oneline. By default, it shows the entire message, and, in my experience, most people aren't going to change the default behavior in one specific case.

Silhouette 6y ago

Git and Subversion even allowing single line “-m” commit messages was a mistake. That's a subjective preference. Maybe for some repos it's a good idea to allow or even require longer messages, but certainly not all. For example, after seeing many different strategies for commit messages over the years, my own preference in many cases is now to permit only one-line commit messages, with a strict character limit, which include a reference to a suitable source such as a feature or bug ID where more details may be found. With git, this can be checked using a pre-commit hook. The big advantage of this is that a `git log` or similar command with a single-line format can never then hide anything important. Assuming we're talking about an established project that does have things like a bug tracker and some sort of structured project documentation set up, I have found that any time I am tempted to write a longer commit message, there is usually a better place I could record that information, and if not then maybe it wasn't that important anyway. YMMV, of course. As I said, it's a subjective preference, and no doubt there are many different ways a team might choose to use their tools.