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

https://joaomagfreitas.link/why-you-should-use-a-terminal-editor-to-write-a-commit-message/

by thunderbong • 2 years ago

7 30 2 years ago

https://github.com/RomanHotsiy/commitgpt

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!

nicolaslem• 2 years ago

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/

calmoo• 2 years ago

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

gear54rus• 2 years ago

All of these issues can be avoided

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

fellerts• 2 years ago

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

persnickety2• 2 years ago

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.

weinzierl• 2 years ago

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

frizlab2• 2 years ago

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

account423• 2 years ago

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.

persnickety2• 2 years ago

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

SAI_Peregrinus• 2 years ago

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.

techjamie• 2 years ago

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

creesch• 2 years ago

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.

cowpig• 2 years ago

I use an alias for `git commit -m`

immdischt• 2 years ago

gcm

bee_rider3• 2 years ago

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

Or something like that

account423• 2 years ago

Thanks, Satan.

frizlab2• 2 years ago

This is a joke, right?

SayMyName• 2 years ago

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

bee_rider3• 2 years ago

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.

JohnFen• 2 years ago

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.

vidalee• 2 years ago

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

paholg• 2 years ago

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/

account423• 2 years ago

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

johnea• 2 years ago

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.

kkfx• 2 years ago

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.

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

Related Stories