5 ms·

Do people not often use "git commit -m" for commit messages? Curious as to the common level of need to launch the full editor.

by mccolin 14y ago

obilgic 14y ago
Writing descriptive commit messages with multiple lines.
- ams6110 14y ago
  $ commit -m 'This is > my long > multi-line message' Granted, if you really want to write a novel that gets inconvenient, but I try to keep commit message short and reference a story or bug id# for more details when necessary.
  - ibotty 14y ago
    i know it was not your point, but pls use a blank line between title and body.
pilgrim689 14y ago
depends. for small commits, a one-liner suffices. For large commits, merge commits, etc., or for repos that require you to sign-off on the commit or whatnot, a one-liner followed by a blank line and then a nice paragraph or bullet-point list is necessary. "launching a full editor" is hardly a problem with emacsclient or vi[m]
- jordibunster 14y ago
  The smaller the commit, the more likely that it needs a proper explanation of why it was made. When you find a commit from two years ago that changes a constant from -1 to -2, and the commit message says "constant change", or "bugfix in floobers" you're left with no context.
deleted 14y ago
[deleted]
mhd 14y ago
If I'm not using some integrated VCS system (which currently happens quite often), it's still mostly the case that I just switched from an editor when I'm writing my CLI commit command. So the mental context switch to transfer back into an editor setting is pretty minimal. And with the editor running (or EDITOR being vi(m)/emacsclient), the startup is negligible, too. So since the time of CVS, and now with either SVN or git, I just don't care too make a difference between small or larger commit messages and completely ignore options of expressing my commit message on the shell, going to the editor all the time. I found that this also encourages me to be a bit more specific about the reasons for the changes committed. A few lines don't really hurt. On the other hand, it might be that my commit schedule might still be too influenced by the older VCS systems, and a more frequent git-ish approach would encourage a more in-line approach. But right now I think that my one or two additional lines help more than they hurt.
vq 14y ago
Even if you do you'll still need EDITOR for interactive rebase.
octo_t 14y ago
Please do not do this. Please. Build up your commit with git add -p (which requires an editor), then git commit -v and check what you are committing again.

Do people not often use "git commit -m" for commit messages? Curious as to the common level of need to launch the full editor.

by mccolin 14y ago

Do people not often use "git commit -m" for commit messages? Curious as to the common level of need to launch the full editor.

obilgic 14y ago

Writing descriptive commit messages with multiple lines.

ams6110 14y ago
$ commit -m 'This is > my long > multi-line message' Granted, if you really want to write a novel that gets inconvenient, but I try to keep commit message short and reference a story or bug id# for more details when necessary.
- ibotty 14y ago
  i know it was not your point, but pls use a blank line between title and body.

pilgrim689 14y ago

depends. for small commits, a one-liner suffices. For large commits, merge commits, etc., or for repos that require you to sign-off on the commit or whatnot, a one-liner followed by a blank line and then a nice paragraph or bullet-point list is necessary. "launching a full editor" is hardly a problem with emacsclient or vi[m]

jordibunster 14y ago
The smaller the commit, the more likely that it needs a proper explanation of why it was made. When you find a commit from two years ago that changes a constant from -1 to -2, and the commit message says "constant change", or "bugfix in floobers" you're left with no context.

deleted 14y ago

[deleted]

mhd 14y ago

If I'm not using some integrated VCS system (which currently happens quite often), it's still mostly the case that I just switched from an editor when I'm writing my CLI commit command. So the mental context switch to transfer back into an editor setting is pretty minimal. And with the editor running (or EDITOR being vi(m)/emacsclient), the startup is negligible, too. So since the time of CVS, and now with either SVN or git, I just don't care too make a difference between small or larger commit messages and completely ignore options of expressing my commit message on the shell, going to the editor all the time. I found that this also encourages me to be a bit more specific about the reasons for the changes committed. A few lines don't really hurt. On the other hand, it might be that my commit schedule might still be too influenced by the older VCS systems, and a more frequent git-ish approach would encourage a more in-line approach. But right now I think that my one or two additional lines help more than they hurt.

vq 14y ago

Even if you do you'll still need EDITOR for interactive rebase.

octo_t 14y ago

Please do not do this. Please. Build up your commit with git add -p (which requires an editor), then git commit -v and check what you are committing again.