TL;DR: What's the interest in updating our release tool (probably as a 10% project) to let us not have to use 16+ characters before we start our summary? Are there any reasonable barriers?
I'm a big fan of the 50/72 commit message line length philosophy, and I think/hope most everyone else here is of the same opinion (but even if you're not, I still think you'll appreciate what follows). As such, I consider those first 50 characters precious and hate wasting them with something like "[CR] [12345678] " - that's a minimum of 16 characters!
Don't even get me started on when it's multiple authors and/or stories…
My name is already in the commit history as the author (and committer), why included it again? Yes, I'm aware that omitting it leaves out the others who helped with the work, but there are solutions for that.
All those brackets aren't needed, especially if we just start with the story number(s). Wouldn't you prefer something like "12345678 - " to start your message? Yay, 5 more characters to work with!
Personally, I still think the story numbers are noise in the summary, and would rather have them on a later line in the commit message where I can grab it if I need it, but I'm not distracted by them.
How many of us know what stories 50276895 and 50263173 are about? There are commits from those stories that aren't even a day old.
There are tools that make writing commit messages as a pair easier, though I haven't spent any time actually evaluating them. There's also the old-fashioned way of writing your commit message manually and adding the stuff as needed (which most of us are probably doing anyway).
While moving information to subsequent lines will make it much tougher to do a git commit –m …
, I'd argue that is for the best. I love my quick git commit messages, but as a result, I don't necessarily put the amount of time/effort into crafting an appropriate git commit message as I should. Being forced to open up the message in an editor would slow me down and hopefully prompt a more thorough commit message.
So, who's up for updating our qa_release_tasks
gem and workflow so they support what I would term as cleaner and better commit messages?
I'd love to hear everyone else's thoughts on this.
No, the reflog stores where it came from for 90 days. Mine only shows stuff from the time I cloned forward, but I don't think that would be a problem on the box that's compiling this data.