
Git commit accepts several message flags (-m) to allow multiline commits - stefanjudis
https://www.stefanjudis.com/today-i-learned/git-commit-accepts-several-message-flags-m-to-allow-multiline-commits/
======
fphilipe
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:

    
    
        $ git commit -m "Fix issue" -m "Lorem ipsum..." -e

~~~
yjftsjthsd-h
I exploit the same trick to have a script automatically set what it thinks a
commit message should be, but still pass it for human review/edit before
actually committing and pushing. Come to think of it, you could easily use
this to set a default message base and do things like always prefix the
directory; I like my commits to be something like "modules/foo: added bar", so
I could just alias gc='git commit -m "${PWD##*/}" -e' (well, something like
that, but more sophisticated).

~~~
delusional
For this usecase git has the 'prepare-commit-msg' hook that allows you to
configure this per repo.

~~~
pletnes
I use this to insert the jira issue key into the commit message.

~~~
mtbnut
Smart. The dev tool I use automatically links my commits to the Jira issue
that initiated the project/fix/update. The key and sha are forever linked. It
does the same with Clubhouse.

------
twicetwice
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.

~~~
cameronbrown
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
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.

~~~
pacaro
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?"

------
tams
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.

If you're using fzf [0] for history recall (ctrl+R) it also has the nice side-
effect for not cluttering up your history.

[0] [https://github.com/junegunn/fzf](https://github.com/junegunn/fzf)

~~~
Agentlien
Another option, if you're using Vim, is to use Tim Pope's Git plugin,
Fugitive[0]

[0] [https://github.com/tpope/vim-fugitive](https://github.com/tpope/vim-
fugitive)

~~~
wadkar
And magit for the emacs folks.

They provide a conceptual framework for developer to orient and frame their
actions with (sort of) right information density in the “native” $EDITOR
environment.

I think VSCode has that git plugin which is very popular but I can’t remember
the name - gives great git log/blame interface.

~~~
sanketdasgupta
GitLens!

[https://marketplace.visualstudio.com/items?itemName=eamodio....](https://marketplace.visualstudio.com/items?itemName=eamodio.gitlens)

------
andy_ppp
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.

~~~
shric
I also like "git branch -d @{-1}" to delete the previous branch, which can of
course be aliased.

------
OnACoffeeBreak
And if -m inline message gets screwed up, --amend to the rescue:

    
    
      git commit --amend
    

This will open $EDITOR and let you edit the commit message. It will also
modify commit content if you stage changes before it.

~~~
masklinn
I've set up an alias for `commit --amend --no-edit`, this way merging new
stuff into a commit is easy, and editing the commit message is just a `-e`
away (`-e` flips `--no-edit` back on).

The only concern is the odd situation where I'd staged something before
realising I was missing bits in the commit message.

~~~
abledon
i love those in alias, gca, gcane.

Then when pair programming I can say "Time to pull out the G-Cane"

------
gorgoiler

      $ git commit -m ‘
      > Bugfix #94
      >
      > Help I’\’’m trapped
      > in a bug fixing
      > factory
      > ‘

~~~
majewsky

      $ echo $SHELL
      zsh
      $ git commit -m $'Bugfix #95\n\nEverything's fine, please move along.'

~~~
gorgoiler
FYI bash also interpolates C escape strings with $’…’ syntax.

The apostrophe in your example breaks the command.

I actually installed zsh and ran this because I assumed your point was that
zsh magically handled the _«‘s»_ in _«Everything’s»_. Alas, no.

~~~
majewsky
And that's why you always test your one-liners before posting. :)

> I assumed your point was that zsh magically handled the «‘s» in
> «Everything’s»

I'm very glad it doesn't. String parsing and expansion rules in Bourne-like
shells are already complex enough as it is.

------
seventh-chord
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.

I would be curious to hear how others view this.

~~~
nurettin
When inheriting a project, you use git blame a lot. Who wrote it, when it was
written and any hints as to why it was written. If it has a task number like
"fixes #1402" and you still have access to the issues, that's great.

If it is like "f*ck python" or "lol java sux" that's a good indication that it
was a syntax problem or a trivial mistake.

If it is like "a" or "aaa" or "x" it's just useless and you are on your own.

~~~
yjftsjthsd-h
> If it has a task number like "fixes #1402" and you still have access to the
> issues, that's great.

 _If_. The flip side is that when you _don 't_ have the issue tracker (I'm
unclear as to whether they deleted it, or it just didn't come along when the
product was acquired), it's _maddening_. "This [massive, opaque] change fixes
#123" "...gee, thanks; that tells me loads."

Ask me how I know.

------
bitdivision
You can also just add a line break inside the ""

e.g.

    
    
      git commit -m "Short commit message
      Longer description
      of my commit"

~~~
steveklabnik
This is shell dependent.

------
sokoloff
Emacs and git users who haven’t tried magit should make a point to try it this
week, IMO.

[0] - [https://magit.vc/](https://magit.vc/)

[1] - Another commenter made the recommendation first, but it is buried in a
thread, so I’m raising it up here.
[https://news.ycombinator.com/item?id=23768518](https://news.ycombinator.com/item?id=23768518)

------
wayneftw
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.

And I do everything with the keyboard.

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.

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.

~~~
MayeulC
Even when using the command line, you typically use an interactive editor to
type your commit. Enter is enough to create a new line.

What you are saying doesn't help when automating things, unless you want to
make a macro that controls the mouse and keyboard? That'd be risky. GUIs are
great for discovering features. So great in fact that the API ("user
interface") often changes, if only by a bit. Terrible if you are in this for
the long run, or want to automate things.

I don't really want this to be a command-line vs GUi thread, but you kind of
started it (even if a bit off-topic).

> but using Shift+Enter to get a newline is fairly common and easy to try and
> guess.

How on Earth is that intuitive? User interfaces (coomand line, GUI, web,
voice) typically rely on common patterns (desktop metaphor, doule click, right
click, alt+letter, F1, ctrl+c, etc) being memorized by their users.

At least, command line interfaces have the merit of often being documented
(that feature is documented line 91 of my offline `man git commit`). I had
overlooked that bit, but had I needed it, that would have been pretty easy to
find. Most GUI software do not even pretend to have documentation anymore (KDE
is still pretty good at this).

command-line vs GUI is a choice. I work most often with the former as I've
grown comfortable with its patterns over time, after seeing it a lot. An added
benefit is that I can often re-purpose the knowledge I learn for writing
scripts. But not everyone necessarily needs to do so. And I think that picking
the same tool for every task is pretty dumb. I like GUIs a lot for stuff I'm
not familiar with, or don't do often.

~~~
throwaway43234
> At least, command line interfaces have the merit of often being documented
> (that feature is documented line 91 of my offline `man git commit`)

By default, pressing "Enter" in VS Code adds a new line. I don't think that
needs to be documented. And the input box for the commit message says as its
placeholder "Cmd+Enter to commit on [branch]", which is a whole lot more
discoverable than going to line 91 of some man page. Plus, every keybinding
can be searched and configured using the built in keybinding editor.

>> but using Shift+Enter to get a newline is fairly common and easy to try and
guess.

> How on Earth is that intuitive? User interfaces (coomand line, GUI, web,
> voice) typically rely on common patterns

You'll find many "Enter to submit" boxes across the technosphere have some way
of adding a new line, typically shiftenter, ctrlenter, etc. So this is a
common pattern.

------
ChrisMarshallNY
I tend to use a GUI (SourceTree) for most of my git work. It allows
(encourages, even) me to write fairly extensive commit messages.

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.

------
40four
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.

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.

------
for_xyz
I always wonder how using cli to commit changes is faster than using dedicated
git frontends such as Fork to do such tasks.

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.

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.

Things like that are impossible to achieve with only using cli productively.

Also I like the ability to see commits from all branches at glance.

~~~
abluecloud
I used to think the same, then I learned a bit more about how to use git on
the cli. I'm not saying you haven't, I'm just saying for me, I was able to
perform tasks quicker with a few tweaks.

Things i've done to do this

\- replace default diff tool (I use [https://github.com/so-fancy/diff-so-
fancy](https://github.com/so-fancy/diff-so-fancy)) \- added many alias for
commonly used commands and ones I often forget \- use `git add -p` (or `g a
-p` in my setup) which goes through changes file by file, allowing me to add
bits i want (this was the main thing I loved about a GUI based git client)

------
wadkar
This whole thread so full of nice tips and hidden gems!!

Thanks everyone :-)

------
mtbnut
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.

------
nchase
This is great to know. For years I've been adding `&& git commit --amend` to
write any amendments.

~~~
battery423
That looks like much more effort then the default behaviour of git commit to
open your editor.

------
rl3
Note that each subsequent use of the _-m_ flag appears to prepend a line feed
to the beginning of the commit message.

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.

------
Havoc
Opens the temptation to write essays. One liners forced a certain brevity

~~~
alderz
I love essays in commit messages! They can be very useful, especially when
they describe why the change is being applied, instead of what is being done,
which is usually the case.

Many high-profile projects have essays in their commits; I'm familiar with
those of Go, e.g.
[https://github.com/golang/go/commit/5779bb4e92911271583faa13...](https://github.com/golang/go/commit/5779bb4e92911271583faa1365fd12be2c3894ee)
(picked one at random).

~~~
aarong11
I like to go with a brief "what i've done and why". Maybe "BUG-123 (Broken
profile page) - Fixed missing CSS".

~~~
xorcist
Why did the bug happen? How were users affected?

Why was this particular "fix" chosen, instead of perhaps a more obvious
alternative? (If I can choose only one thing to improve, it'd be this one! Had
I gotten a penny for every head scratching "fix" that seems unnecessarily
complicated or not a fix at all...)

What steps have been taken to avoid this in the future? New validations? Have
new exceptions been introduced? New log rules? New monitoring rules? And if
not, then why not?

Are these corresponding changes in other repos or this one? Is this change
part of a larger series of changes?

There's so much more you'd like to know when you stumble on a commit like "fix
missing css". Yes, some of this info is probably in the ticket. Yes, there is
probably a discussion in the pull request. But likely not, if we are to be
honest about it. And if it is, then all the easier to summarize in the commit
message.

I'm one of those persons that read more code than I write nowadays, git log -G
is my favorite command, and commit messages like the above hurts me daily.

~~~
simias
I've already made a similar comment elsewhere in this discussion but I really
don't get why most of these things is better stored in a commit message than,
say, as a comment in the code itself, which will always be here even if I'm
just browsing through the code by following a call stack or if the file gets
copied into another project for instance.

I don't "git blame" all the code I read all the time, and even if I did one
small refactor or variable renaming is enough to make it tricky to track the
original change back. Comments are forever.

~~~
xorcist
Comments and commit messages are complementary. The commit message describes
the _changeset_ and includes things like the above, the whys and the necessary
context to understand the change. The comment describes the actual _code_ as
it is, and should describe how it works and how it interfaces with other code.
Comments tend to be, as you say, forever while the code changes.

Both are well worth the time to write. Nicely written ones might even take a
full minute or two to write, but how many cleaned-up and rebased commits does
one produce in a day? A few, at most, unless they are absolutely trivial.
Those minutes per workday are well spent.

------
k_
... why did it never occur to me? x)

Small issue: your last sample has a copy/paste mistake, it says `[master
2fe1ef8] first line` with "first line" instead of "commit title"

------
throwaway_pdp09
Yep, amazing what you can learn when you read the manual.

------
est31
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.

------
baalimago
What's wrong with not flagging -m at all and simply writing a structured
commit message in your cli text editor of choice?

------
jatinmistry13
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`.

------
MrOxiMoron
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

------
bobbyd3
+1 for the -m option and commit messages :P

------
arun6582
Awesome!!!

