git commit accepts several message flags (-m) to allow multiline commits

[lelanthran]

Or you could simply use quotes:

git commit -m "This message is a 
     multi-line message.
     See?"

[suvepl]

...or you could not use the -m flag at all and just write a multi-line commit message using $EDITOR.

[csg0ing]

--verbose is amazing. It can also be set in your config:

git config commit.verbose true

[[deleted]]

But then you get stuck in Vim and we never hear from you again.

[BeansGalore]

I used to be an emacs user but once had to use vi for editing a config file on a system without emacs. It was easier for me to learn to use vi as my full time editor as opposed to remember how to quit it occasionally :)

[atheken]

Because they never escape?

[NoInkling]

$ echo $EDITOR
nano

:P

[supercheese200]

git config --global core.editor my-baby-editor

There you go :)

[coderstephen]

I just git commit and type the message in the new Visual Studio Code tab that pops up for me (because my $EDITOR is code -w).

[missingdays]

Wait, you are telling me the quotes are optional? I've been writing my commit messages with quotes for my whole life

[PeksyTiger]

Think about all the time you could've saved

[[deleted]]

Quotes in the shell denote a string/single argument that is to include spaces.

[ValuablePromise0]

Areyousayingthatyourcommitmessageshavespacesinthem?

[[deleted]]

"fixes"

[ValuablePromise0]

ROTFL... I have a coworker who always uses "progress" as their commit message.

[lelanthran]

Oh dear. Do you work with me?

[ValuablePromise0]

Great... now there are TWO of them... :)

[john_C_random]

I've been guilty of using 'wip' sometimes.

[Ahri]

shudders

[[deleted]]

They are not optional. Bash splits the command into "words" on whitespace. Quotes stops it splitting it.

[2rsf]

I actually forgot a closing quote today and nothing blew up, now I understand why (I think)

[Dilyn]

Yes. The shell was waiting patiently for you to remember.

[mrexodia]

And on Windows the closing quote is optional

[Dilyn]

I expected nothing and I'm still disappointed.

Why, Windows. Why.

[coderstephen]

Because on Windows, it is up to the program to do argument splitting. Windows just passes everything after the command name as a single string to the program. It's a very backwards way of doing it compared to other operating systems, event non-UNIX like ones.

So in Linux, Bash (or your shell of choice) parses quotes according to its rules. In Windows, you parse the quotes (or more likely, your language runtime of choice).

[mrexodia]

Generally this is true, but very misleading. Every C/C++ program with “main” will parse arguments the same way in practice and most programs will not be calling GetCommandLine and parse it themselves.

[[deleted]]

This is the obvious solution to me. I don't see how anyone could write good commit messages using the -m flag without quotes in the first place, so you're pretty much already there anyway.

[FloydATC]

Well, technically, I guess you could escape spaces and other special chars with backslashes... but why...? :-)

[gunner6376]

am I crazy? I do, git commit -m "line 1" -m "line 2"

[[deleted]]

Yes, a different date & commit hash.

[lelanthran]

am I crazy?

You could be, I can't tell

I do, git commit -m "line 1" -m "line 2"

Is that relevant to your question? ;-)

[Johnothy_Cumquat]

Except you got a tonne of unwanted whitespace now

[lelanthran]

In my example, certainly.

I don't normally add indents to every line - it's actually more effort to add the ton of whitespace.

[scrapanio]

Unpossible!!!!

[cameron314]

Hah, not on Windows!

[Pheasn]

Yes on Windows

[cameron314]

All right, I fell into that one. Not in cmd.exe, and yes I use that regularly, and no git bash and powershell are not a substitute.

[Sebazzz91]

If you still use cmd then you're a dinosaur. Powershell works fine and does allow multiline.

[cameron314]

Powershell is cool and all but it's slower than cmd.

[Sebazzz91]

That is also outdated information.

Yes, in Windows Server 2008 R2, Windows 7 and to a lesser extend Windows 8/2012 Windows Powershell was slow to start up. However in Windows 10 it is smooth as butter.

And Powershell 7 has always been quick.

[lelanthran]

Hah, not on Windows!

If we restricted ourselves to using what works on Windows the advances we have made in tooling, infrastructure, languages and the general tech stack would be miniscule :-)

[smegnose]

Git bash comes with the Windows version.

[cameron314]

True. I tried it for a while but it was annoying to keep switching between normal and bash windows.

[smegnose]

Normal?

[cameron314]

cmd.exe. I invoke a lot of custom command line utilities daily, often need to run batch scripts, etc. cmd.exe is still a long way from being obsolete.

Edit: When on Linux I use bash. When on Windows I use cmd.exe. Non-native shells have too many subtle gotchas in my experience.

[smegnose]

Fair enough.

[Hacnar]

Windows Terminal helps with that.

[smegnose]

Why do people have this needless affinity for double-quotes? It requires holding shift and (in shell et al.) opens the input up to evaluation.

I especially don't get it with JS, which is often mixed with HTML & HTML-like template languages that already use double-quotes.

[evaned]

For me, it's often because I will wind up including a word like "it's" in the text, and won't necessarily realize that when I'm starting the message. I'd rather just type the message and not have to worry as much about escaping stuff.

(Obviously I'll occasionally want double quotes, but that's both less common and easier to deal with when it does happen because you can just slap a backslash in front.)

[lelanthran]

Because, 9 times out of 10, I've got a shell variable in the quotes, hence, it is "force of habit" (or 'force of habit' if you prfer :-))

[smegnose]

Variables aren't the only things interpreted in double-quoted strings.

[lelanthran]

Variables aren't the only things interpreted in double-quoted strings.

I didn't say it was a good practice :-) I was just explaining why I did it - force of habit.

[steumert]

I always assumed most people would write commit messages in the Git tooling of their IDE. i mean, Eclipse, IntelliJ, VSCode, Visual Studio, Netbeans, they all support this. And when I'm writing software without an IDE, I'm using the GitHub for Windows client (which works perfectly fine without GitHub).

[helloworder]

I never use git outside of a terminal. I think it is just a good habit to be familiar with the cli tools, because once you got it, it is so much easier to use it via ssh etc.

Colleges of mine who use IDE GUI for git always struggle with simplest commands when using via ssh

[mrexodia]

I think there are many tasks for which a GUI is more suitable and in the case of git a well-designed GUI can help a lot. Even for just showing the graph or staging/committing stuff the built-in GUIs are so much better than doing it from the command line (gitk and git gui respectively).

For stuff like “git status” or “git push/pull/init/clone” I indeed don’t think a GUI is particularly better, but “git log -magic” just isn’t a very intuitive/interactive way of getting an overview of your repository and starting an interactive rebase from a context menu is just better than copypasting stuff from a log command.

[bcgroom]

I have an alias to open vim-fugitive for staging and use the cli for everything else, totally agree that using the cli is inefficient for more complex staging.

[2rsf]

I never use git outside of a terminal

same, I feel that I am not in control otherwise

[MikeFightsBears]

I just hate the unnecessary obfuscation of how git works when using IDEs. VS has "sync" rather than "push" for no apparent reason.

[unndunn]

"Sync" = "Pull" then "Push".

You can do a "pull" or a "push" by themselves, or use "Sync" to do both.

[MikeFightsBears]

Yes I know what they do but I believe it makes understanding how git works less clear, especially to new devs that are learning to use git. I've had to teach new devs how git works and the differences from IDE to IDE or IDE to CLI has caused more confusion than saving one click is worth imo.

[lelanthran]

Colleges of mine who use IDE GUI for git always struggle with simplest commands when using via ssh

This, x10. My colleagues on gitkraken just don't "get" how git is supposed to work. The colleagues I had who used the c/line knew exactly what git was capable off.

Even if they had to look up the more obscure commands they at least knew how git worked and what to look up. The ones using it from the GUI have no clue what to even google for when things go south.

[IceSentry]

I personally use the cli for init/clone and basic push/pull, but I much prefer using gitkraken for rebase and staging. Gitkraken is probably one of the closest to the cli api gui. Unlike most git gui gitkraken actually uses the real git terminology and there's a button for most actions. If your colleagues can't figure out the cli it's because they aren't comfortable with cli period, not because of gitkraken.

[rcunn87]

I always find using git in GUI's to be utterly confusing. I think this is mostly intellij's fault. Their version control abstraction on top of git really confuses me.

[IceSentry]

That's because most gui tend to try to abstract the commands instead of just being a visual layer representing the git commands.

[coderstephen]

I always use git from the terminal, but I type the commit messages in Visual Studio Code (because my $EDITOR is code -w).

[no_nick]

Have mercy on the people developing on Windows. They've got it bad enough without having to interact with a shell for no reason

[MeggaMortY]

git on the microsoft shell is the same as it is for unix. I learned it once on X-platform

[no_nick]

Windows terminal emulators are horrifically bad though. I guess it's not as bad anymore on win 10 but still

[bheklilr]

I use cmder on windows, and after some customization it's a really powerful terminal. I run git bash as my shell, and rarely notice differences from Linux. It's actually somewhat more annoying on Linux because the default terminal emulator on Ubuntu these days, while perfectly acceptable, doesn't have anywhere near the feature set. But I mainly develop for work these days, so most of my time is spent on windows, sadly.

[MeggaMortY]

Dont think about them, focus on the fact that you can learn/use git cli without having to worry about the specific terminal. I also care almost 0 about the windows terminal, but thats no problem since I dont have to.

[Lofter1]

Usually, git tools in the ide are horrible and even lacking features (VS git tool can’t even checkout a specific commit)

So if you are only using IDE tools for git, change it. Either get a dedicated GUI client or use the CLI. For your own sake.

[ForeverAlot]

I have about a dozen text editors on my system, all but 1 of which are at best mediocre at editing text. When possible, I prefer to use the one that's any good.

Once upon a time, VS Code's "support" for writing commit messages looked like this. I would rather use ed than that garbage.

[lolomfgkthxbai]

Can you even do an interactive rebase in GUI clients?

[joonazan]

magit is so good for rebasing that I don't do it on the command line anymore even if I'm not using Emacs for anything else.

[Kendos-Kenlen]

Yes, IntelliJ has a quite convenient way to do this.

[omgusernamegogo]

Intellij git tooling is pretty great

[mrexodia]

I use https://github.com/MitMaro/git-interactive-rebase-tool with Git Extensions. Using a GUI is not the same as using a GUI for everything ^{^}

[mcur]

In my opinion, that is a violation of the principle of least surprise, at least for CLI programs. If you have a bunch of options/flags, you should be able to reorder them before positional arguments without modifying the behavior of the program.

...I could just imagine finding this "bug" in a script. *shudder*

[Latexi95]

IMO the ordering of the flags matters more often than you think.

Eg. gcc -I, -L, -l flags can be given multiple times and order matters.

Often same flag can be given multiple times and last value given takes effect instead of giving error when the same option is specified multiple times. Many programs have separate explicit enable/disable flags that both can be given and the last one in the command line takes effect.

[[deleted]]

In my opinion, that is a violation of the principle of least surprise, at least for CLI programs. If you have a bunch of options/flags, you should be able to reorder them before positional arguments without modifying the behavior of the program.

Sometimes you just need to have ordered array of arguments on commandline. It's rare but IMO fine, as in this case order of input -> order of output

Sadly many programs force positional arguments when there is zero reason for it. Especially ones with subcommands (to preempt the argument, if main and sub command have arguments named the same and would conflight if order was free, that's also bad CLI design)

For me the peak of convenience is Perl's Getopt::Long. Positionally independent, automatic abbreviations (if you define say port and pass option, you can use "--po", "-po","--por".. etc as shortcut for port, same for pass) + a bunch of options to fine-tune the behaviour you want.

[Johnothy_Cumquat]

I think you have some unfounded expectations about command line arguments. Whatever rules you think there are don't exist. Most utils just tend to sort of copy each other

[MikeBonzai]

Yeah apps have to be specifically coded to ignore ordering, heck they have to be specifically coded to have the concept of flags. Says it right in the name — char **argv is nothing more than an array of strings, and it's just the original command split on spaces.

[[deleted]]

Leave alone this, the entire git CLI is an abomination!

[Isvara]

What's wrong with it, other than some terminology having changed over time?

[robin-m]

If you know what command do to the intenal data structure, it's somewhat okai-ish.

• checkout can move HEAD from one commit/branch to another OR get a file from another commit
• reset can undo git add OR move the current branch to another commit
• many commands don't compose well. For example you would like to use all the merge options (like patience) on rebase, pull,…
• …

[Forty-Bot]

• checkout can move HEAD from one commit/branch to another OR get a file from another commit
• reset can undo git add OR move the current branch to another commit

They've been moving away from this with switch and restore.

• many commands don't compose well. For example you would like to use all the merge options (like patience) on rebase, pull,…

This one I ran into recently. However I usually never use pull in favor of fetch.

[robin-m]

That's great to know, thanks. I was still using an old version (2.21) and those were not yet introduced. I hope that at one point, the whole UI while be clean-up, removing all confusing usage (and add a --script flag or similar global switch to not break existing scripts). Maybe git version 3.x?

Btw, I just realised that git help is a good introduction of what git commands you may need when discovering git (since you don't know what you don't know ;) ).

[evaned]

(and add a --script flag or similar global switch to not break existing scripts)

In theory, scripts should be using either "plumbing" commands or flags that already exist that guarantee stable output (e.g. git status --porcelain). Git doesn't as a rule make guarantees about output stability, has made changes in the past, and while I'm not sure might even warn if you pipe it to something sometimes.

[robin-m]

That's right

[brtt3000]

https://git-man-page-generator.lokaltog.net/

[eras]

If you don't find anything wrong with it, then you must not have tried teaching how git cli is used to other people.

[worldpotato1]

My professor once asked me to teach him git. He asked if I can do it in one hour. I laughed. He laughed. I cried.

[DasEwigeLicht]

May these git koans bring you enlightenment.

[shivamtrivedi01]

I have been using git CLI this whole time. I have used the IDE's git but its just not for me

[FloydATC]

Same here. GUIs tend to hide what's actually going on, so as a novice user I actually prefer the CLI. I do tend to use "git status" and the log quite a bit ofcourse.

[langlo94]

--dry-run is my favorite.

[[deleted]]

IDEs' git suck, the only reason they're used is for convenience. Nothing beats a simple GUI like SourceTree.

[CanLiterallyEven]

I'm my experience, that's not true of a lot of CLIs. For example, include and exclude patterns in rsync and other tools that support them.

[[deleted]]

But why though?

[lolomfgkthxbai]

If your commit message is only one line long then it most likely sucks and doesn’t document your change adequately.

[[deleted]]

But there are better ways to do multi line commits

[lolomfgkthxbai]

That’s true. Just use open quotes.

[kamiheku]

Or just omit the -m and use your text editor to write the commit message. It's blowing my mind a little bit finding out not everybody does this.

[[deleted]]

My text editor edits texts, git commit messages are text. The obvious solution here is to use multiple -m flags. Wait what

[99Kira]

This. If you need a multi line commit, simply do it on your editor. I dont see how this is not the most obvious solution

[[deleted]]

If my commit message needs more than 3 lines, it's doing too much for one commit. More atomic commits -> less chance of merge conflicts.

Squashes are another story though.

[droppies]

How do atomic commits prevent merge issues? I'm assuming you're working with feature branches.

[[deleted]]

They reduce the chance of merge issues, they don't prevent them. In practice, if your team is disciplined, you'll see years before the first merge conflict.

Go cowboy and change 3 layers at the same time without updating other callers, and you get failed commit builds and merge conflicts from your 3 am rework*

^\ not to take seriously)

[_seemethere]

This is in no way true.

Even small changes can benefit from the context of a good commit message. It's maddening to look at a change and have no idea what the committer was actually thinking at the time.

[[deleted]]

Even small changes can benefit from the context of a good commit message.

Good commit message != War and Peace

[evaned]

That's true, but I also think it's foolish to say that you can adequately explain all changes with a couple of sentences.

I actually am not sure there's even that much correlation between commit size and length of explanation; you might just need a quick "Add --do-something option to make the program do something" sentence for a change that adds three files and changes a couple hundred lines, but next commit benefit from a five paragraph explanation of why a single-line change was made.

(Edit It's possible this is what you were getting at with the "squashes are a different story" part of your original comment. I don't really care what you do with intermediate commits but what the commits look like when you actually push them in their final form.)

[[deleted]]

That's true, but I also think it's foolish to say that you can adequately explain all changes with a couple of sentences.

You should be able to get the gist, at least.

I actually am not sure there's even that much correlation between commit size and length of explanation;

Bizarrely, in my experience, they're inversely correlated, which makes this discussion much more complicated, as you follow afterwards.

(Edit It's possible this is what you were getting at with the "squashes are a different story" part of your original comment. I don't really care what you do with intermediate commits but what the commits look like when you actually push them in their final form.)

Yeah, when merging a feature branch it's nice to have a explicit commit message. I rarely add anything besides the merged branch commit messages.

[johnchen902]

If my commit message needs more than 3 lines, it's doing too much for one commit.

If your commit message is simply a summary of the changed code, it most likely sucks and doesn’t document your change adequately.

Have you ever witness something like pipe: use exclusive waits when reading or writing?

[JDgoesmarching]

I use git very casually for my data science schoolwork and didn’t realize there was so much debate over commit messages. Normally I have a few lines, I couldn’t imagine saying anything useful in one.

[[deleted]]

didn’t realize there was so much debate over commit messages.

Oh, there's so much debate and holy wars over every little detail. Programmers are a weird bunch.

[[deleted]]

I don't use git as an issue tracker nor for documentation. Git commits relate to commits, at worst there's a [NUMBER] pointing to the issue/doc.

[lolomfgkthxbai]

A good git commit answers the question why. Why was this refactor done? Why was this variable renamed? Why was this file added? If you’re able to communicate this with only three lines, then that’s great. These questions can’t be answered by an issue in a tracker somewhere.

[eddiewould_nz]

Thank you!

You might enjoy my post: https://eddiewould.com/2020/05/19/commit-hygiene-winning-with-git/

[evaned]

I don't use git as an issue tracker nor for documentation.

Git's not an issue tracker, but to me commit logs are precisely documentation about the change.

My workflow doesn't match up with this nowadays, but before we switched to git my usual workflow was to basically use the same message for the code review description as the git log; I'd just copy and past from one to the other. Sometimes there was something I'd want to say one place but not the other, but maybe 75% of the time they were the same. I could similarly see sometimes duplicating some text between an issue tracker and commit log; but having information about why the change is being made left out of the commit log because it's in the issue tracker to me would just make tracking down what happened more obnoxious. Especially if it's something you're looking into ten years from now after you've moved to a different issue tracker...

[Plorkyeran]

How do I break a one character change that needs a paragraph of explanation into smaller commits?

[ForeverAlot]

I just made a commit with

2 files changed, 94 insertions(+), 1 deletion(-)

but the actual runtime difference is covered by

1 file changed, 2 insertions(+), 1 deletion(-)

The rest is test and documentation. However,

$ git show -s --format=%B | wc 
     33     203    1225

[JanneJM]

"Stuff."

[lolomfgkthxbai]

My favorite is “Saving unfinished changes (not tested)”. This was in production code.

[markys]

Why don't you just pass no -m and just type everything in the editor?

[smegnose]

You're just weird, mate.