A very descriptive commit that doesn't actually fix the bug, only removes the offending character that was triggering it.
My Favourite Git Commit
381–389 of 389 posts
Re: My Favourite Git Commit
#382Earlier quoted context omitted.
I work at a place that used to prescribe this. I dislike it because it adds too much repetitive noise to the abridged git log. (It occurs to me that you may be making this point in a tongue-in-cheek way.) Originally I suggested we put the JIRA number/link in the commit body, but then I learned about git-notes to add metadata to commits and now I kinda want to do this with the semantic labels suggested by the thread O…
Notes kinda bloat the repository with additional objects, and they can be removed independent from the commits, so I'm a bit iffy on using them for this.
Good points to consider, thanks! It’s good to know all the tradeoffs.
Re: My Favourite Git Commit
#383Earlier quoted context omitted.
> Oh. Locales. The remembered pain. More like the ongoing pain. I had to write the following just this year because SQL Server still defaults to using CP 1252 for text. The culprit? One of those damned stylized quotes that Office loves to insert for you. The code: def _wrap_str(value: str): try: return SqlVarChar( value.encode("cp1252") ) except UnicodeEncodeError: logging.getLogger("bulk copy").exception(f"value cau…
I would call that Windows pain at this point, not locales. In the Linux/Postgres world, everything is UTF-8. Which is the default for all internet protocols. Do that and the pain is gone. Of course Windows doesn't do that...
Linux is not entirely UTF-8, though plenty of people treate it as if is so. Even if on Linux, you might need to consume files from other OS's or other Linux systems with different locales. Once had issues with systems configured with "C" locale vs "en-US" should have been near identical, but enough slight differences to cause failures. Been +10 years, so I dont remember the details.
Windows, the OS, is UTF-16 (or UCS-2 - I forget the details between the two), SQL Server has, for historical reasons, defaulted to CP1252, probably for compatibility with Office components.
But, it's not really a Windows problem, per se, because you have to deal with this issue if you deal with data originated from numerous Windows apps, even if on Linux. Yeah, you can insert a byte order mark (BOM) to indicate UTF-8, but most tools expecting UTF-8 actually dont check for the BOM and blow up in interesting ways if present. Ive seen this far too many times. Enough that anytime I see an encoding error from the likes of Python or Ruby, its an instant recognition (I do a lot ETL work from a number of vendors, so I see a lot of different files "types").
Re: My Favourite Git Commit
#384The Holy Order of Git Commit Log Bikeshedding and Overengineering have their field day. And they all have it wrong. Any commit log that doesn't compile to an automated build script isn't worth the bytes it's made of.
Re: My Favourite Git Commit
#385Re: My Favourite Git Commit
#386Earlier quoted context omitted.
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…
I fix about 2~4 issues by day, 20~40 commits by day. If I do write a blog post for every commit my productivity will down by 70% at least.
Re: My Favourite Git Commit
#387Earlier quoted context omitted.
"It should start with a capital letter, then move to lowercase, and necessarily will start with a verb.", are you seriously?
Can you elaborate on your surprise or objection? It may not be obvious to onlookers what you're reacting to.
well, I think if you start with this kind of bureaucracy, you're doing it wrong. It's not funny. Also, if your app is down, clients calling and you need to fix it fast. If I need to remember this rules to fix this, people will kill me, or I will kill myself :p
Re: My Favourite Git Commit
#388Earlier quoted context omitted.
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…
I fix about 2~4 issues by day, 20~40 commits by day. If I do write a blog post for every commit my productivity will down by 70% at least.
Well that's the argument about immediate productivity and good documentation.
Re: My Favourite Git Commit
#389Earlier quoted context omitted.
Can you elaborate on your surprise or objection? It may not be obvious to onlookers what you're reacting to.
well, I think if you start with this kind of bureaucracy, you're doing it wrong. It's not funny. Also, if your app is down, clients calling and you need to fix it fast. If I need to remember this rules to fix this, people will kill me, or I will kill myself :p
After a few days practicing this, it becomes second nature, and doesn't hold you up at all. Commit histories also become much quicker to parse through, especially with "log --oneline".
I notice no hindrance on my speed because I write good commit messages, and always value them when I one back to them.