61–70 of 389 posts
OR 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.
One of my favorite pranks is to put control characters in the commit message (like the bell) and then you get an auditory notification anytime anyone nearby opens your commit messages.
I love these commits. Then don't have to be this verbose, but they have to tell a story of why things were done. I can sort of deduce the what from the code itself, but the why is sometimes shrouded in mystery. I started with these explanatory git commits a few months ago and they are super useful, even if you're just reading your own commits from some time ago.
OR 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 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…
Related question: are there projects that use git itself as issue tracker?
OR 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 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…
Comments about the code should be in the code, where the next dev will see it. The more trivial a change, with far- reaching implications, the more important this is.
Doing so has heaps of benefits: future devs understand ramifications, shows that this code has been scrutinized, makes it easier when doing refactoring /yanking, or porting code.
That said, leaving the life story out will always be a good idea.
I wish Git wasn't like some generic term for source control. A little diversity is good!
I love these commits. Then don't have to be this verbose, but they have to tell a story of why things were done. I can sort of deduce the what from the code itself, but the why is sometimes shrouded in mystery. I started with these explanatory git commits a few months ago and they are super useful, even if you're just reading your own commits from some time ago.
To me they are red flags because it means that very likely who writes this kind of commit messages doesn’t use a proper issue tracking system.
When you change or switch to a different ticketing system, you will bring these with you.
I often review commit logs of my teams, especially while we are tracking down problems or I'm making sure the release notes capture everything. There has to be a balance between this and "WIP"; I'm imagining trying to page through the commit log to see what changed when every 1 line change has a 35 line commit associated with it.
The first line is the title, then there's a description.
These heavy descriptions of commits, are used quite heavily in linux kernel dev
OR 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 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…
Your future maintainer will thank you for not having to dig through repository history.
For anybody wondering, the likely origin of the invalid character is somebody using an Apple Ireland/UK keyboard layout where # is Option-3 (AltGr-3), and non-breaking space is Option-Space (AltGr-Space).
I don't know how many times these non-breaking spaces caused problems. I think linters should prevent commits that contain non-breaking spaces. And if really one is needed, it should be encoded as ` ` or with whatever encoding is relevant.
Such as UTF-8?