Conversation

Notices

1. Darius Kazemi (darius@friend.camp)'s status on Tuesday, 03-May-2022 23:12:55 UTC Darius Kazemi

   I've got a new blog post up at Meedan (where I work). It's about longform git commits: what they are and how they can make your life as a software developer easier.

   My spiciest git take is you should ban "-m" from your git repertoire and go full verbose invoking a text editor from the CLI to write commits.

   https://meedan.com/blog/how-to-write-longform-git-commits-for-better-software-development/

   • Santa Claes 🇸🇪🇭🇰🎅 repeated this.
   • Darius Kazemi (darius@friend.camp)'s status on Tuesday, 03-May-2022 23:12:48 UTC Darius Kazemi

     in reply to

     • Evan

     @darth_mall Yeah it's why I tried to use my "modal" example there.

     Something that I didn't mention in the article is it's a way of documenting like... how MUCH work went into a commit. Sometimes you have a ~1 line commit that took you all day. A verbose commit is where you can really show your team why that took all day (and it is likely to help someone in the future since tiny changes with huge ramifications should be well-documented!)

     Santa Claes 🇸🇪🇭🇰🎅 likes this.
   • Evan (darth_mall@vis.social)'s status on Tuesday, 03-May-2022 23:12:54 UTC Evan

     in reply to

     @darius I wish I could convince people to quit using `-m`. Whenever I run Git workshops at work, I try to motivate the use of your Git logs as documentation and why you should go ahead and open up a text editor for your commit message.

     I don't know that I've ever convinced anyone, though…

   • Darius Kazemi (darius@friend.camp)'s status on Tuesday, 03-May-2022 23:13:36 UTC Darius Kazemi

     in reply to

     • Scott Feeney

     @graue yes, correct on -m.

     What I like about having this in git is that it stores the important information in git rather than in github dot com

     Santa Claes 🇸🇪🇭🇰🎅 likes this.
   • Scott Feeney (graue@mastodon.online)'s status on Tuesday, 03-May-2022 23:13:42 UTC Scott Feeney

     in reply to

     @darius I tend to put those longform descriptions in pull requests, but I see how it could be valuable to have them in the commit message.

     When you say ban "-m", surely you mean except for WIP/checkpoint commits that will be rebased/squashed later, right?

   • Michael McClimon (mmcclimon@oldinternet.net)'s status on Tuesday, 03-May-2022 23:14:40 UTC Michael McClimon

     in reply to

     @darius You probably know this, but you can set commit.verbose true in your config and never have to remember -v again! This is also really useful because you get it mid-interactive-rebase, when it’s a little harder to pass -v manually.

     Santa Claes 🇸🇪🇭🇰🎅 likes this.
   • Santa Claes 🇸🇪🇭🇰🎅 (clacke@libranet.de)'s status on Wednesday, 04-May-2022 02:03:28 UTC Santa Claes 🇸🇪🇭🇰🎅

     in reply to
     @darius I use -m all the time for multi-line commit messages!
   • Santa Claes 🇸🇪🇭🇰🎅 (clacke@libranet.de)'s status on Wednesday, 04-May-2022 02:10:33 UTC Santa Claes 🇸🇪🇭🇰🎅

     in reply to
     I also consider the ticket number absolutely essential and our subject line standard mandates it when applicable (and it should normally be applicable).
     
     The point about punctuation is a good one, and I will ususally commit with a draft message from the CLI and then immediately run git commit --amend to fix it up a bit.
     
     But then I will also most of the time run interactive rebases and fix things up, both code and messages, before pushing things.
     
     I will take this moment to evangelize --rebase-merges which is an absolute godsend and really helps with separating things into focused, topical PR branches.
     
     @darius
   • :flan_reaper: (lordbowlich@hackers.town)'s status on Wednesday, 04-May-2022 02:29:21 UTC :flan_reaper:

     in reply to

     • Santa Claes 🇸🇪🇭🇰🎅

     @clacke @darius

     We've got some advocates at my work for putting it in the body instead of the subject line, but I do find it essential to have the ticket number available in the short history.

   • Santa Claes 🇸🇪🇭🇰🎅 (clacke@libranet.de)'s status on Wednesday, 04-May-2022 02:29:21 UTC Santa Claes 🇸🇪🇭🇰🎅

     in reply to

     • :flan_reaper:
     @lordbowlich @darius Yes. If I'm about to deploy to prod, I want to be able to see at a glance in my git lg* which features will be included in the deploy and we will put ticket numbers in the release notes too, and in the subject of mails discussing aspects of a feature, etc.
     
     * basically a git log --graph --decorate --oneline but with a little bit more candy, see gitlab.com/clacke/gists/-/blob…
   • Santa Claes 🇸🇪🇭🇰🎅 (clacke@libranet.de)'s status on Wednesday, 04-May-2022 11:51:52 UTC Santa Claes 🇸🇪🇭🇰🎅

     in reply to

     • Mark Stosberg
     @markstos @darius Sounds quite like the C4 format:Problem: the thingamjigs smurf too much
     
     Solution: transmogrify the flerps
   • Mark Stosberg (markstos@mastodon.online)'s status on Wednesday, 04-May-2022 11:51:59 UTC Mark Stosberg

     in reply to

     @darius Yes. I encourage a #git commmit message body format of "Before, …
     Now, …
     Issue: CMO-123"