Gah... About a third of my commit messages are just "minor cleanup" or a variation. Should I be ashamed?
I think shame is an awful motivator. Instead I would praise you for identifying an opportunity to improve :)
My Favourite Git Commit
341–350 of 389 posts
Re: My Favourite Git Commit
#342Earlier quoted context omitted.
Seems like they are. Also seems like a solid practice that far too many people ignore.
or you can say something equivalent yet unambiguous A good commit message isn't about convention, and no convention makes a commit message good. When I review a commit, I need only the information I won't get from the diff that I need to understand the context and the behavior. My brainpower is a limited resource and extra noise in my signal is extra work. I'm totally here for `ISSUE_123456 fixes defect` and `wip` ar…
At my work we almost encourage the blog post in there idea.
It's not a hard and fast rule and it's ok to ignore it when it makes sense. But we also don't mind if your commit message takes longer to write than the code took to change and debug.
A lot of context is assumed in commits, and almost all of it is temporal. Capturing as much of that as possible pays off down the line.
Commit in the article is a good example where the context explains much more than the change.
(On the flip side, the pay off has an expiry date so I'm not extremely fussed when people lax, but it's still good to check in basic assumptions whith your code)
Re: My Favourite Git Commit
#343General education in a commit is questionable... OTOH find -exec and escaping the ';' (or '+' for xargs-like one line) was helpful (hard to parse --help, though manpage is clear). Now I don't know what to think.
Re: My Favourite Git Commit
#344Earlier quoted context omitted.
Yeah. People who use the term "retarded" that way are stupid, no matter how smart they are.
I disagree. Words are just words and we give them meaning. Being derogatory and unkind to mentally deficient folks is ethically wrong. Using that word in a different context to communicate frustrating imo is fine.
Wait until a derogatory word being used effects you directly. It's really easy to just not use words flippantly that you know some people have an issue with. You are clearly aware of how it can be offensive and for a lot of people your definition is still just a callback to people being unkind about mental illness. History matters too and if you choose to ignore that and use it anyway you're just being unnecessarily inconsiderate.
Re: My Favourite Git Commit
#345I use the following convention to start the subject of commit(posted by someone in a similar HN thread): Add = Create a capability e.g. feature, test, dependency. Cut = Remove a capability e.g. feature, test, dependency. Fix = Fix an issue e.g. bug, typo, accident, misstatement. Bump = Increase the version of something e.g. dependency. Make = Change the build process, or tooling, or infra. Start = Begin doing somethi…
Some additions I personally use:
- Change: change functionality or behavior.
- Cleanup: more than formatting, less than refactoring. No functional changes.
- Rename: refactoring that changes a name but does nothing else.
- Extract: refactoring that creates a new module or class by moving code out of an existing module or class.
Re: My Favourite Git Commit
#346seems like the commit messages lines are in reverse order.
tell me what you did.
then tell me why you did.
leave the saga for the end text so I don't have to read through your musings to get to the meat.
Re: My Favourite Git Commit
#347I use the following convention to start the subject of commit(posted by someone in a similar HN thread): Add = Create a capability e.g. feature, test, dependency. Cut = Remove a capability e.g. feature, test, dependency. Fix = Fix an issue e.g. bug, typo, accident, misstatement. Bump = Increase the version of something e.g. dependency. Make = Change the build process, or tooling, or infra. Start = Begin doing somethi…
Every commit message must start with JIRA ticket number
This is a good way to; complicate development, slow down development and add an unnecessary dependency of jira...
Re: My Favourite Git Commit
#348I use the following convention to start the subject of commit(posted by someone in a similar HN thread): Add = Create a capability e.g. feature, test, dependency. Cut = Remove a capability e.g. feature, test, dependency. Fix = Fix an issue e.g. bug, typo, accident, misstatement. Bump = Increase the version of something e.g. dependency. Make = Change the build process, or tooling, or infra. Start = Begin doing somethi…
Every commit message must start with JIRA ticket number
That sounds awful, but I/we do name feature branches as team-(TICKET TITLE),with the title as usually optional
Re: My Favourite Git Commit
#349Earlier quoted context omitted.
> I don't want your entire life story in my commit log. I[1] want enough debug information in the commit log to be able to reproduce the issue without having to go on web hunts to understand the problem. Especially when the change appears to be trivial on the surface, because these are the ones that can turn out to be rabbit holes. I don't want to have to interrupt you to get this information because you didn't write…
This. It's the same with comments in code: I don't want to read what the code does (I can read that myself, thanks!), I want to know WHY it does it the way it does it - especially, if there is a more obvious, better way. Also: People leave companies. Or die. At some point in time, you won't be able to ask the original author.
No thanks. If I had a dime for every function that's so obviously self-documenting to what it does.. etc. If you tell others what it does and why, concisely and thoughtfully, no one has to try and mentally parse the what of some clever undescriptive block of code.
Re: My Favourite Git Commit
#350OR you could just write Replace invalid ASCII char. Fixes rake error 'invalid byte sequence in US-ASCII'. I don't want your entire life story in my commit log.
I, too, would rate this a substandard git comment.
Dave basically vomited a bug ticket of information, which is highly contextual and irrelevant ... like the lines he was faced with, which tell us nothing in the future nor anything we could not see in the change. The error is known, from the ticket being addressed. Documenting what error a bundler throws in the application deployment, within git seems...silly, since it will likely not apply to all points in time. That's why we have separate issue tracking.
There was a whitespace encoding issue AND the developer didn't really understand the issue, since they ended with "One hour of my life I won't get back.". Over my 20 years, I've seen this EXACT scenario multiple times across multiple companies. Some jr engineer gets stuck with some troublesome weird error in a corner-case that ends up being a non-standard whitespace. It's a learning opportunity and he lamented it because it was different and nobody told him "we could stop this from happening again, generate a new issue".
There are salient improvements that the git commit would benefit from both comment changes and additional code:
1. Include a (new) feature ticket that is linked to this issue - to create a process that doesn't allow for this again (eg fix a linter)
2. Include the name of the bug ticket (Convert template to US-ASCII to fix error) in the commit title, that was being addressed.
3. Create a test to specifically enforce the us-ascii encoding or add necessary rules to a linter.