Why you should use a terminal editor to write a commit message | Hacker News Reader

Why you should use a terminal editor to write a commit message

joaomagfreitas.link

7 pointsthunderbong30 comments

Wait do people write all their commit messages with `-m`? No wonder they're always so bad.

I use an editor to write commit messages because it lets me take my time, to format them, to edit them after the initial draft.

If I know the message will be under 50 characters, I might use `-m`, but the rest of the time I want an editor.

Always relevant: https://cbea.ms/git-commit/

1, 2.: This expense of time is about as much as it takes for the editor to open, and then to close it again.

4. Pre-commit hooks are an anti-pattern. The repo creator has no business messing with my local, half-broken experiment/exploration commits. Do that on push if you must.

5. The dual: oh, you passed the wrong flags to commit and you remembered this after you started to write the commit message? Too bad, the mess is yours to fix now.

The one reason that completely convinces me is 3. It's not worth the pain to enter a multi-line commit on the command-line. -m is for one-liners.

You can use -m multiple times to create multiline commit messages.

Plus multi-line work (in zsh at least) when using quotes.

> 4. Pre-commit hooks are an anti-pattern. The repo creator has no business messing with my local, half-broken experiment/exploration commits. Do that on push if you must.

Git hooks are not part of the version controlled repository so you can already set them to whatever you like (for anything executed local anyway, push hooks are up to the remote).

You can also bypass them using --no-verify for cases where you consider that to be the right thing to do.

Weird, I never once set them myself but I've been subjected to them a couple times. Is my laptop developing gremlins?

Someone might have given you a command to run when setting up a repo. For example, it’s standard practice to download a hook which assigns a Change-Id to each commit when using Gerrit.

1 & 2 sound like the person doesn't know how to touch type. An adult who types as a major part of their job should easily be able to hit 70-80 WPM (5.8-6.7 characters per second) when copying random words, faster for actual typing. If ` -m "` and `"` (6 extra characters) is costing you more than a second, you should make an alias and also practice typing.

Seriously, what programmer is having a hard time finding " on their keyboard?

Mh...

1. err, firing up an editor, type the message, save and quit is not quicker...

2. on my keyboard they are on a single key (I have inverted number/symbol row), my environment (Emacs/EXWM for some things my QMK firmware) automatically pair relevant symbols)...

5. various shells have history, easy navigation etc, so well... Not that hard...

6. I hardly imaging putting special chars in a commit message...

To me the main reasons might be: commit messages should often have a short line title THAN a more broad prose, witch is a good reason to use an editor. If your editor is not nano but something more featuresful you might like templates and so on. The rest seems to be a bit... Considerations by someone who not use much a shell, so it's not comfortable with it.

The main reason to use an editor is not included: multi-line commit meesages

I continue to see commit messages by people using IDEs that have long single line commit messages.

A short summary line, which shows as the one line commit message in gitk et al, then a detailed commit messages that can be pages long in some cases is the ideal form.

Some commits only need a 1 line message, but others need long detailed blocks of text. When this is the case, having that short summary, and a blank line separating the lengthy details gives correct presentation in all git tools.

I do find value in your approach, but I'm just so used to the -m approach that I would hesitate to use another one. It helps me make sure to be brief and get to the point with the commit. The editor would give me too much freedom and I am likely to ramble!

> The editor would give me too much freedom and I am likely to ramble!

Please do! Context not included in the commit message or the code is lost forever.

How to Write a Git Commit Message: https://cbea.ms/git-commit/

These are pretty nitpicky reasons but you should use the editor simply because doing so makes it more likely that you will include additional lines with relevant context (freeform text and/or links, issue numbers etc.).

I just use VS Code's commit message box, easier than CLI in my opinion (I also like VS Code's git commit flow)

> All of these issues can be avoided

... if you use a gui in front of git :)

Same, I just wish there was a way to hard-wrap the lines at 80 characters inside that box.

I mostly just use whatever my IDE provides to do commit messages ¯\_(ツ)_/¯

Other than that, this feels over the top, to the point of satire on opinions in tech?

If typing two extra characters actually does cost you valuable time then you possibly need to reevaluate your work pressure or possibly amount of commits.

If you have trouble finding quotes on your keyboard, your blind typing skills just suck. Also, what language are you even coding in?

Remembering to not press enter is on the same level as learning to use nano (use vi you peasant!).

I guess some of the arguments are valid... in some environments.

This is a joke, right?

This sounds more like a post by the Senior Dev that you don't want on your team. It's a commit message, use whatever is quickest/easiest for you...

Seems more like the opinions of a beginner who’s just recently discovered the joy of the terminal, and is in the zealous honeymoon phase, to me.

I non-ironically want to be around when they discover vim!

It's just one guy saying what his preference is. There's no global right or wrong on this sort of thing, there's just what works best for each dev.

https://github.com/RomanHotsiy/commitgpt

I use an alias for `git commit -m`

gcm

    :au BufWritePost * !git commit -a -m “Automatically commit crimes against my git history”

Or something like that

Thanks, Satan.

Thank me not my child, we serve only ourselves. Now, go forth and ply my corruption as you see fit.

Feeling that these are mostly nitpicks to be honest:

- The first two reasons are quickly invalidated once muscle memory is in place.

- I rarely break line and keep my commit messages short, but that depends of your workflow I guess, in my case the information is mostly in the linked ticket.

- If you accidentaly press enter and need to amend, you don't need to write the message again, just edit the part you want in the editor.

- My terminal do not have render issues.

- For the pre-commit hook it's been a while since I used one on commit messages, but how does it check the message validity before commiting using a terminal editor ?

TL;DR: the only point I found applicable in my case is the argument on special characters (such as $), but it never happened to me for now

Reply on news.ycombinator.com