This article was originally published on http://shreyasminocha.me/blog
I totally obsess over commit messages. I often spend minutes staring into...
[Read Full]
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.
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)
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)
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.
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
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 !
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.
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?
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).
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.
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!
My commit message workflow
Shreyas Minocha on June 22, 2018
You could probably use grep -v instead of perl in your prepare-commit-msg hook
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 > $1but that didn't work.Eventually, the following worked:
Any better way to do this with
grep -v?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)
Why not use sed?
You could do the following:
sed -i '/\(# Please.*\|# with.*\|^#$\)/ d' $1The
-iflag 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
sedstatement - There was a missing "/" (fixed now)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 BSDsed(the one that macOS uses) requires an extension with-i. However, even that gives mesed: 1: "/^# Please/,+2 d": expected context address. Apparently the+2thing 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 ofsed.Does the other
sedcommand work for you (sed -i.bak '/\(# Please.*\|# with.*\|^#$\)/ d' $1)?You can also try this one:
sed -i.bak '/^# Please/,/^#$/ d' $1To keep things tidy you could make it
sed -i.bak '/^# Please/,/^#$/ d' $1 && rm $1.bakPerfect.
I usually use the first message from What The Commit, but I get weird looks from my coworkers afterwards.
That website is my new source of entertainment.
omg mine too. Thanks @antogarand !
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/
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-msgcan be configured to support those, though.For anyone having a hard time setting the
core.editor, the command should be$ git config --global core.editor 'sublime -n -w $1:2'Thanks for pointing that out. I've added some links to installation instructions.
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?
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).
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.
thanks for share it. I can't understand "pet peeve",sorry
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.
A pet peeve is just something that someone finds extremely annoying, more so than other things that might be an annoyance.
I didn't know about the seven rules, thank you!
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
I did stumble across it some time back but the
type(scope): messageformat isn't for me. I've been experimenting with git-mojis though 😃Very good article with some helpful links, thanks!
This is great! I've been wanting to implement a structure for commits at my job and this seems like a really great jumping off point. Thanks!
Great article; I have a iTerm badge with the message "If applied, this commit will..." :)
Can you show a screenshot of your git log to see how this looks?
Sure. Here's a
git log --onelinefrom the repo for my school's MUN's website.Link to screenshot
I was hoping to see how your template was used
Oh! The template's just comments. All lines beginning with '#' are ignored. Here's an example of how it would be used.
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!
Awesome article, thanks for sharing!