Why you should use a terminal editor to write a commit message(joaomagfreitas.link)
joaomagfreitas.link
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/
31 comments
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 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/
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/
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.
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.
> 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.
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?
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.
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.
I use an alias for `git commit -m`
[deleted]
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...
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.
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
- 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
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/
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/
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.).
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.