What's cool is that if you start with -m and add a second -m but notice that you have more to say than initially expected, you can still pass -e to open the editor with the message entered so far:<p><pre><code> $ git commit -m "Fix issue" -m "Lorem ipsum..." -e</code></pre>
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.
The -v option, which the author is referring to when talking about writing commit messages in vim is much better: you get to author the commit message in the $EDITOR of your choice and you can inspect the full diff while doing so.<p>If you're using fzf [0] for history recall (ctrl+R) it also has the nice side-effect for not cluttering up your history.<p>[0] <a href="https://github.com/junegunn/fzf" rel="nofollow">https://github.com/junegunn/fzf</a>
My favourite git shortcut is "git checkout -" it mean switch back to the previous branch, so without having to remember either branch you can switch between two pieces of work easily. This seems to come from "cd -" which does the same thing with the current and the previous directory.
And if -m inline message gets screwed up, --amend to the rescue:<p><pre><code> git commit --amend
</code></pre>
This will open $EDITOR and let you edit the commit message. It will also modify commit content if you stage changes before it.
Do people actually read commit messages? I don't have much experience working on large projects with a larger team, but I keep repositories both for personal things and work so I can look at older versions. I have however never actually looked at my own commit messages, even though I try to keep them informative. I instead search through commits based on strings added/removed or file paths touched.
As such, multiline commit messages (whether added on the command line or via the editor) seem doubly pointless to me.<p>I would be curious to hear how others view this.
You can also just add a line break inside the ""<p>e.g.<p><pre><code> git commit -m "Short commit message
Longer description
of my commit"</code></pre>
Emacs and git users who haven’t tried magit should make a point to try it this week, IMO.<p>[0] - <a href="https://magit.vc/" rel="nofollow">https://magit.vc/</a><p>[1] - Another commenter made the recommendation first, but it is buried in a thread, so I’m raising it up here. <a href="https://news.ycombinator.com/item?id=23768518" rel="nofollow">https://news.ycombinator.com/item?id=23768518</a>
While CLI users are reading article after article to discover hidden features of their tools, I'm using a GUI that makes those features obvious and streamlines actions to make my work go faster than any CLI user could possibly achieve outside of automating their workflow entirely.<p>And I do everything with the keyboard.<p>I do this on Linux, Mac and Windows with VS Code. Before I used VS Code, on Windows I'd use TortoiseGit - again, all with the keyboard. I can operate the entirety of Windows with just a keyboard and most of XFCE on Linux.<p>To be fair, entering multiple lines of text into the VS Code Git commit sidebar is somewhat "hidden" as well, but using Shift+Enter to get a newline is fairly common and easy to try and guess.
I tend to use a GUI (SourceTree) for most of my git work. It allows (encourages, even) me to write fairly extensive commit messages.<p>One of my tricks is to copy the entry I made in my CHANGELOG.md file, and make that part of my commit message. I may add a bit of extra to it, in order to establish a technical context.
I went an embarrassingly long time without knowing you could use a second -m flag. I tend to do all my git stuff on the command line. Since I learned this, I have made it a regular habit to add more detailed messages to my commits when necessary. Very helpful when looking back at old history, to remember details or problems I encountered while working on that commit.<p>I see a lot of people say they always use vim to edit commits, I think I will have to try this out. The -m flags in the terminal have always worked fine for my workflow, so I guess I never really thought about using vim.
I always wonder how using cli to commit changes is faster than using dedicated git frontends such as Fork to do such tasks.<p>I used to use it like that but it was too much work to manage multiple repositories in such way especially if i didn't remember all changes I made.<p>Using Fork greatly reduced time spent making useful commit messages by having all changes visible at glance. It even allows to stage specific lines of source code and has insanely good interactive rebase UX.<p>Things like that are impossible to achieve with only using cli productively.<p>Also I like the ability to see commits from all branches at glance.
I use Gitbook to create dev docs and it incredulously doesn’t pass merge messages to GitHub via its integration. A big fail, imho. All you see in GitHub is “Gitbook updated ## files.” I mention this because I could use this flag to see if I can add a manual process to get my messages assigned to corresponding commits.
Note that each subsequent use of the <i>-m</i> flag appears to prepend a line feed to the beginning of the commit message.<p>This results in more of a paragraph-style spacing, rather than true multiline. You can see this in the author's own screenshots, or just by trying it yourself.
... why did it never occur to me? x)<p>Small issue: your last sample has a copy/paste mistake, it says `[master 2fe1ef8] first line` with "first line" instead of "commit title"
This is great as it leaves the second line empty without you having to specify. It's a common mistake for people to put stuff onto the second line.
why not just use `git commit` without the `-m` flag and when the terminal editor opens, type the commit message in the editor?
That way you can format the commit message however you want and write whatever you want. And when you want to update the commit message just do `git commit --amend`.
my got foo is good enough that a GUI will only get in the way of what I want to do. But I never use the -m flag. Seeing the files that a I'm about to actually commit in my $EDITOR saved me a lot of headache because I forgot to add a file or added one that shouldn't have been. also really helps with writing extensive commit messages that actually describes the changes and why a certain solution was chosen. Was often grateful to my past self for writing down why I implemented it in a certain way and what other things I tried before that didn't work. Saved a lot of time retrying the same failed solutions