7 ms·

I'm not sure I've _ever_ used the -m flag to write a commit message. Naked `git commit` defaults to vim for me, and that's how I like it. Multiline messages, te

I'm not sure I've _ever_ used the -m flag to write a commit message. Naked `git commit` defaults to vim for me, and that's how I like it. Multiline messages, text turns from yellow to white when you go over 80 characters, summary of changes when you're writing the message, the ability to abort with :q! — I can't say the number of times I've realized I left a bug or forgot to tweak something or stage a change while writing a commit message, and bailed out to fix that before committing — the list of advantages goes on and on. I'll never not write my commit messages in vim, and I encourage everyone to do the same.

petepete 6y ago
The only time I use it is when I'm making a small fix or tweak and will be `rebase -i`ing immediately afterwards. It probably saves me several keystrokes per year.
- twic 6y ago
  For that case, commit --fixup and rebase --autosquash might save you even more.
rplnt 6y ago
I always use oneliners. Task ID + some short description. Used to use just `-m`, but nowadays I almost exclusively use lazygit to commit. At work we squash PRs and that's where we can write more details if necessary, or just hope the associated PR with details will be available in the future. For my personal projects, I don't care that much. When I realize a mistake, there's always amend.
vthriller 6y ago
You don't even need to quit editor without saving changes, you can just ^Z it, add new changes, fg the editor back and continue with your commit message.
- yakshaving_jgt 6y ago
  This is me all the time. [is writing commit message] Oh wait… What did I change? ^Z git diff --cached Oh yeah. fg
  - for_xyz 6y ago
    That workflow seems really slow when dealing with multiple repos/subrepos actively compared to what UI frontends offer. But it's still more efficient method for single repository project where using UI git client would be the overkill.
  - gonzus 6y ago
    You should be using `git commit -v` then; it will include the full diff of your changes, so you can quickly check them while writing your commit message.
    - seemethere 6y ago
      Yeah this is what I use, the only issue being extraordinarily large commits may get bogged down some times. I have no idea why anyone would ever not use this to be honest.
- u801e 6y ago
  I actually type my commit messages in a new window in the editor (vim). :r !git status -v Type my commit message above the output, and then visually highlight the lines of my commit message and then run :'<,'> !git commit -F - In fact, if I see an issue with the diff, I can update the relevant file and then run: :!git add % and then go back to the window with the status output, delete it and rerun the status -v command. In fact, if I want to be more fine grained with the changes I stage in git, I can run: :r !git diff to get the output of the unstaged changes, copy the hunk header lines, paste them above the hunk I want to stage, visually highlight the hunk with the header lines, and then run: :'<,'> !git apply --cached - to stage that hunk. I've even done things like using recountdiff to update the hunk header if I decide to removed added lines or restore deleted lines in a hunk. Personally, I think it's easier than using git add -p or reset -p.
g-b-r 6y ago
Sometimes it's very convenient to start writing your message in the command line, either to delay the "mental context switch" from the command line to vim or when you want to prepend some fixed text to a series of commits. You can just add -e to the end to either finish writing or checking it in Vim then, which is what I almost always do when I use -m.
simias 6y ago
I use -m often, it's pretty much my default commit method. It doesn't break the flow, I can see the previous commands in the terminal above which is sometimes useful. Besides it's trivial to change the commit in an editor if you're not happy with it with a simple "git commit --amend". It's even possible to change your mind in the middle of the commit command by adding '-e' as somebody else helpfully pointed out in this comment section. I mean, I don't think my way is superior to yours, but I don't think it's inferior either. It's just a matter of taste and workflow I suppose. In particular I don't really see why editing text in vim is going to make you more or less likely to realize that you forgot to "tweak something or stage a change". And at any rate as long as you haven't pushed anything it's trivial to rewrite the commit.
- ghayes 6y ago
  I think the biggest difference is once I switched away from `-m`, I tend to write multi-line commit messages. Specifically, I do a title line and a full description in the commit message itself. GitHub will pick this up (if you have a single FF commit) and automatically populate a pull request description with your commit's title and message. As a side-effect, you have a detailed history available for all code patches.
yjftsjthsd-h 6y ago
> summary of changes when you're writing the message -v makes this so much better - forget seeing the list of files in the commit; you can see the whole diff! :)
- deleted 6y ago
  [deleted]
cameronbrown 6y ago
For anything other than personal projects where messages don't matter much, -m is an anti-patern. Any good commit message should have at least a paragraph explaining the rationale, functional change and maybe links to design docs or bugs. All the time I come across commit descriptions from decades ago, that are useful because of this.
- simias 6y ago
  I personally tend to write pretty short commit messages, I think any important info is better stored either in comments in the code or the module's documentation. Who goes digging into old commit messages to understand what a piece of code does? I know I don't. Not to say that verbose commit messages are a bad thing, it's always better to have too many details than not enough, but I think very long commit messages might also sometimes hint that either the commit is "too big" and should've been broken down in smaller, atomic changes or, as I said above, that you're really just writing documentation and that may be better suited for an other place. Commits should definitely be descriptive and accurate, but if you break your changes in small chunks you can generally still do that in one or two sentences in my experience.
  - Leherenn 6y ago
    I think long commit messages make sense for bugs, because unless it breaks compatibility you're not going to comment the code every time you fix a bug.
  - pacaro 6y ago
    In my day job I'm frequently chasing down older code, looking through blame/annotate etc. Commit messages with links to bugs and docs are often the fastest answer to the fundamental questions "Why is this thus? What is the reason for this thusness?"
  - u801e 6y ago
    > Who goes digging into old commit messages to understand what a piece of code does? I know I don't. A lot of people do. If you've ever used git blame on a file, you can see which commit each line in the file is associated with. You can then run git show <sha1> for that commit and see the message and associated diff. Having that information can help you understand why a change was made and may help you avoid introducing regression type errors.
recursive 6y ago
I'm pretty sour on vim after being forced into it by `git commit` with no introduction or explanation.
- parliament32 6y ago
  Not git's fault, it uses your OS's EDITOR and VISUAL environmental vars (same thing you get when you run, for example, "crontab -e" and other utilities that want a visual editor).
  - recursive 6y ago
    Hm. I don't think I had such a variable prior to the installation of git. Edit: In fact, still don't. The git editor seems to be configured by some git config rather than environment variables.
    - raggi 6y ago
      The behavior is mostly congruent with other programs, for example less(1) probably also falls back to vi(1) on your system if you press v.
      - recursive 6y ago
        I should clarify, I'm using Windows, which normally doesn't have either of those, except for maybe cygwin or WSL.
      - takeda 6y ago
        TIL, had no idea about that `less` starts an editor on `v`.
- fomine3 6y ago
  Kind announce on Windows https://www.osstuff.com/wp-content/uploads/2019/01/install-git-in-windows-10-9-500x389.png https://www.osstuff.com/wp-content/uploads/2019/01/install-g...
staycoolboy 6y ago
"-m" can be used by automatiom. One of our teams' integrations uses this when automated commits are performed in response to certain actions. E.g., they trigger webpacker builds automatically which are then committed in response to a tag, sprint completion, or other action. (We used to use git hooks which I thought were better, IMHO.)
hoorayimhelping 6y ago
I use -m as a natural filter for line length. If it's unwieldy to fit inside a -m cli flag, it's usually an indicator I can be more concise in my commit message. Obviously, from time to time you'll need to include more information in commit messages; I have sublime set up to be my default editor for these situations.
TouchyJoe 6y ago
How do you make naked `git commit` default to emacs?
- tjdetwiler 6y ago
  git config --global core.editor <EDITOR>
  - steveklabnik 6y ago
    It also respects $EDITOR, though that would impact more than just git, of course.
- mulmen 6y ago
  I believe the default is simply to open your default editor so just set $VISUAL (and $EDITOR, read the manual for your shell) in your environment. This has the added benefit (?) of using that editor for commands that open a visual editor such as crontab -e or even visudo (with some caveats of course). If you want to use a different editor just for git you can set $GIT_EDITOR in your environment.

petepete 6y ago

The only time I use it is when I'm making a small fix or tweak and will be `rebase -i`ing immediately afterwards. It probably saves me several keystrokes per year.

twic 6y ago
For that case, commit --fixup and rebase --autosquash might save you even more.

rplnt 6y ago

I always use oneliners. Task ID + some short description. Used to use just `-m`, but nowadays I almost exclusively use lazygit to commit. At work we squash PRs and that's where we can write more details if necessary, or just hope the associated PR with details will be available in the future. For my personal projects, I don't care that much. When I realize a mistake, there's always amend.

vthriller 6y ago

You don't even need to quit editor without saving changes, you can just ^Z it, add new changes, fg the editor back and continue with your commit message.

yakshaving_jgt 6y ago
This is me all the time. [is writing commit message] Oh wait… What did I change? ^Z git diff --cached Oh yeah. fg
- for_xyz 6y ago
  That workflow seems really slow when dealing with multiple repos/subrepos actively compared to what UI frontends offer. But it's still more efficient method for single repository project where using UI git client would be the overkill.
- gonzus 6y ago
  You should be using `git commit -v` then; it will include the full diff of your changes, so you can quickly check them while writing your commit message.
  - seemethere 6y ago
    Yeah this is what I use, the only issue being extraordinarily large commits may get bogged down some times. I have no idea why anyone would ever not use this to be honest.
u801e 6y ago
I actually type my commit messages in a new window in the editor (vim). :r !git status -v Type my commit message above the output, and then visually highlight the lines of my commit message and then run :'<,'> !git commit -F - In fact, if I see an issue with the diff, I can update the relevant file and then run: :!git add % and then go back to the window with the status output, delete it and rerun the status -v command. In fact, if I want to be more fine grained with the changes I stage in git, I can run: :r !git diff to get the output of the unstaged changes, copy the hunk header lines, paste them above the hunk I want to stage, visually highlight the hunk with the header lines, and then run: :'<,'> !git apply --cached - to stage that hunk. I've even done things like using recountdiff to update the hunk header if I decide to removed added lines or restore deleted lines in a hunk. Personally, I think it's easier than using git add -p or reset -p.

g-b-r 6y ago

Sometimes it's very convenient to start writing your message in the command line, either to delay the "mental context switch" from the command line to vim or when you want to prepend some fixed text to a series of commits. You can just add -e to the end to either finish writing or checking it in Vim then, which is what I almost always do when I use -m.

simias 6y ago

I use -m often, it's pretty much my default commit method. It doesn't break the flow, I can see the previous commands in the terminal above which is sometimes useful. Besides it's trivial to change the commit in an editor if you're not happy with it with a simple "git commit --amend". It's even possible to change your mind in the middle of the commit command by adding '-e' as somebody else helpfully pointed out in this comment section. I mean, I don't think my way is superior to yours, but I don't think it's inferior either. It's just a matter of taste and workflow I suppose. In particular I don't really see why editing text in vim is going to make you more or less likely to realize that you forgot to "tweak something or stage a change". And at any rate as long as you haven't pushed anything it's trivial to rewrite the commit.

ghayes 6y ago
I think the biggest difference is once I switched away from `-m`, I tend to write multi-line commit messages. Specifically, I do a title line and a full description in the commit message itself. GitHub will pick this up (if you have a single FF commit) and automatically populate a pull request description with your commit's title and message. As a side-effect, you have a detailed history available for all code patches.

yjftsjthsd-h 6y ago

> summary of changes when you're writing the message -v makes this so much better - forget seeing the list of files in the commit; you can see the whole diff! :)

deleted 6y ago
[deleted]

cameronbrown 6y ago

For anything other than personal projects where messages don't matter much, -m is an anti-patern. Any good commit message should have at least a paragraph explaining the rationale, functional change and maybe links to design docs or bugs. All the time I come across commit descriptions from decades ago, that are useful because of this.

simias 6y ago
I personally tend to write pretty short commit messages, I think any important info is better stored either in comments in the code or the module's documentation. Who goes digging into old commit messages to understand what a piece of code does? I know I don't. Not to say that verbose commit messages are a bad thing, it's always better to have too many details than not enough, but I think very long commit messages might also sometimes hint that either the commit is "too big" and should've been broken down in smaller, atomic changes or, as I said above, that you're really just writing documentation and that may be better suited for an other place. Commits should definitely be descriptive and accurate, but if you break your changes in small chunks you can generally still do that in one or two sentences in my experience.
- Leherenn 6y ago
  I think long commit messages make sense for bugs, because unless it breaks compatibility you're not going to comment the code every time you fix a bug.
- pacaro 6y ago
  In my day job I'm frequently chasing down older code, looking through blame/annotate etc. Commit messages with links to bugs and docs are often the fastest answer to the fundamental questions "Why is this thus? What is the reason for this thusness?"
- u801e 6y ago
  > Who goes digging into old commit messages to understand what a piece of code does? I know I don't. A lot of people do. If you've ever used git blame on a file, you can see which commit each line in the file is associated with. You can then run git show <sha1> for that commit and see the message and associated diff. Having that information can help you understand why a change was made and may help you avoid introducing regression type errors.

recursive 6y ago

I'm pretty sour on vim after being forced into it by `git commit` with no introduction or explanation.

parliament32 6y ago
Not git's fault, it uses your OS's EDITOR and VISUAL environmental vars (same thing you get when you run, for example, "crontab -e" and other utilities that want a visual editor).
- recursive 6y ago
  Hm. I don't think I had such a variable prior to the installation of git. Edit: In fact, still don't. The git editor seems to be configured by some git config rather than environment variables.
  - raggi 6y ago
    The behavior is mostly congruent with other programs, for example less(1) probably also falls back to vi(1) on your system if you press v.
    - recursive 6y ago
      I should clarify, I'm using Windows, which normally doesn't have either of those, except for maybe cygwin or WSL.
    - takeda 6y ago
      TIL, had no idea about that `less` starts an editor on `v`.
fomine3 6y ago
Kind announce on Windows https://www.osstuff.com/wp-content/uploads/2019/01/install-git-in-windows-10-9-500x389.png https://www.osstuff.com/wp-content/uploads/2019/01/install-g...

staycoolboy 6y ago

"-m" can be used by automatiom. One of our teams' integrations uses this when automated commits are performed in response to certain actions. E.g., they trigger webpacker builds automatically which are then committed in response to a tag, sprint completion, or other action. (We used to use git hooks which I thought were better, IMHO.)

hoorayimhelping 6y ago

I use -m as a natural filter for line length. If it's unwieldy to fit inside a -m cli flag, it's usually an indicator I can be more concise in my commit message. Obviously, from time to time you'll need to include more information in commit messages; I have sublime set up to be my default editor for these situations.

TouchyJoe 6y ago

How do you make naked `git commit` default to emacs?

tjdetwiler 6y ago
git config --global core.editor <EDITOR>
- steveklabnik 6y ago
  It also respects $EDITOR, though that would impact more than just git, of course.
mulmen 6y ago
I believe the default is simply to open your default editor so just set $VISUAL (and $EDITOR, read the manual for your shell) in your environment. This has the added benefit (?) of using that editor for commands that open a visual editor such as crontab -e or even visudo (with some caveats of course). If you want to use a different editor just for git you can set $GIT_EDITOR in your environment.