DEV Community

My commit message workflow

Shreyas Minocha on June 22, 2018

This article was originally published on http://shreyasminocha.me/blog I totally obsess over commit messages. I often spend minutes staring into...

Read full post

shaiay • Jun 22 '18

You could probably use grep -v instead of perl in your prepare-commit-msg hook

Shreyas Minocha • Jun 23 '18 • Edited

I tried this out and it almost worked except grep doesn't allow you to edit a file in-place. So I tried grep -Ev "(# Please.*|# with.*|^#$)" $1 > $1 but that didn't work.

Eventually, the following worked:

grep -Ev "(# Please.*|# with.*|^#$)" $1 > /tmp/msg
cat /tmp/msg > $1

Any better way to do this with grep -v?

shaiay • Jun 23 '18 • Edited

According to SO this is really a limitation of UNIX. The best answer I found there is (stackoverflow.com/a/29735702/5863381)

but really your solution is just fine. You can add some error checking (and make it into a one-liner):
grep -Ev .... %1 > /tmp/msg && cat /tmp/msg > $1
(this way the cat will only execute if the grep didn't produce an error)

James Evans • Jun 26 '18 • Edited

Why not use sed?
You could do the following:
sed -i '/$# Please.*\|# with.*\|^#$$/ d' $1
The -i flag will do the edits in-place, saving you having to create a temp file.
Assuming that the unwanted block always occurs at the same place, you could also do sed -i '/^# Please/,+2 d' $1 (Which will delete the line starting with "# Please" and the next 2 lines as well)

**Just noticed a typo in the second sed statement - There was a missing "/" (fixed now)

Shreyas Minocha • Jun 26 '18 • Edited

Great idea. I'll update the article to use this.

Edit: I just tried this on macOS and it errors out with sed: 1: ".git/COMMIT_EDITMSG": invalid command code .. With some searching, I learnt that BSD sed (the one that macOS uses) requires an extension with -i. However, even that gives me sed: 1: "/^# Please/,+2 d": expected context address. Apparently the +2 thing is GNU sed specific. The first statement (with -i.bak) didn't error, but didn't remove the lines either. I'm guessing it's because of inconsistencies in implementations of sed.

James Evans • Jun 28 '18 • Edited

Does the other sed command work for you (sed -i.bak '/$# Please.*\|# with.*\|^#$$/ d' $1)?
You can also try this one: sed -i.bak '/^# Please/,/^#$/ d' $1

To keep things tidy you could make it sed -i.bak '/^# Please/,/^#$/ d' $1 && rm $1.bak

Shreyas Minocha • Jun 28 '18

Perfect.

Antony Garand • Jun 22 '18

I usually use the first message from What The Commit, but I get weird looks from my coworkers afterwards.

Shreyas Minocha • Jun 24 '18 • Edited

That website is my new source of entertainment.

rhymes • Jun 27 '18

omg mine too. Thanks @antogarand !

Adrian Skar • Sep 9 '20 • Edited

Great! In case someone else needs it;
For the cursor on the first line thing on VS Code
[core] editor = \"C:\\[yourPath]\\Code.exe\" -g $1:1 --wait
in .gitconfig seems to do the trick.

-VSCode's CLI opts

Pavel Savchenko • Jun 26 '18 • Edited

Brilliant stuff! By the way, have you ever tried the GitSavvy plugin? If you did, why did you stop ? If you didn't, please try it out and let me know what you think !

Disclaimer: I occasionally contribute to GitSavvy

Also, I'd like to update your examples to use conventionalcommits.org/

Shreyas Minocha • Jun 26 '18

I'll try Git Savvy out, thanks. Yeah, I've heard of conventional commits, but they aren't for me. Whatever works for you, of course. node-commit-msg can be configured to support those, though.

Jason Ware • Jun 26 '18

For anyone having a hard time setting the core.editor, the command should be

$ git config --global core.editor 'sublime -n -w $1:2'

Shreyas Minocha • Jun 27 '18

Thanks for pointing that out. I've added some links to installation instructions.

Vasconcelos 🇧🇷 • Aug 16 '18

thanks for share it. I can't understand "pet peeve",sorry

Shreyas Minocha • Aug 16 '18

That is perfectly fine. It's a very specific pet peeve and I obviously don't expect everyone to relate to it. Feel free to interpret parts of the post as a proof of concept—such manipulation is possible.

Devin W. Leaman • Aug 16 '18

A pet peeve is just something that someone finds extremely annoying, more so than other things that might be an annoyance.

Nagarjun Palavalli • Jun 26 '18

How would you enforce this practice within a team of developers all committing to the same project? Does Git allow you to globally enforce commit templates for a repository?

Levente • Jun 29 '18

Just FYI, we work on a product (Commit Policy Plugin for Jira) that does just that. It's a Jira app, so it's hard wired to work in Jira, but allows you to enforce all kind of rules (to many VCS, not just Git).

Shreyas Minocha • Jun 26 '18

Good question. As far as I know, no, it doesn't. If there's a neat way to do this, I'd like to know.

Joel Louzado • Jun 28 '18 • Edited

Please tell me you've used commitizen; I'd love to see what kind of customizations you'd do with it. Especially incorporating git-mojis :D

Shreyas Minocha • Jun 28 '18

I did stumble across it some time back but the type(scope): message format isn't for me. I've been experimenting with git-mojis though 😃

rhymes • Jun 27 '18

I didn't know about the seven rules, thank you!

Jason Gade • Jun 24 '18

Very good article with some helpful links, thanks!

alextrastero • Jun 26 '18

Great article; I have a iTerm badge with the message "If applied, this commit will..." :)

John Costanzo • Jun 22 '18

Can you show a screenshot of your git log to see how this looks?

Shreyas Minocha • Jun 23 '18 • Edited

Sure. Here's a git log --oneline from the repo for my school's MUN's website.
Link to screenshot

John Costanzo • Jun 23 '18

I was hoping to see how your template was used

Shreyas Minocha • Jun 23 '18 • Edited

Oh! The template's just comments. All lines beginning with '#' are ignored. Here's an example of how it would be used.

# If applied, this commit will…
Fix the Secretariat page on phones

# Explain why this change is being made

# Provide links to any relevant tickets, articles or other resources
Resolves issue #4

It's meant to be used as a guidance in framing the commit message in accordance with the seven principles I linked to in the article. I'm sorry that it wasn't clear. I've edited the article to make that obvious. Thanks!