I like spending some extra effort on my Git commits (really, typing a message like this doesn't take that long, compared to the amount of time spent doing the change in the commit). It's just a shame that both GitLab and GitHub do not render Markdown in the body of the commit messages, and present them like actual prose rather than a wall of monospaced text.
My Favourite Git Commit
361–370 of 389 posts
Re: My Favourite Git Commit
#362Earlier 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...
SQL Server prior to 2019 stores unicode data in UCS-2 (UTF-16 analog, rougly).
SQL Server 2019 supports UTF-8.
Re: My Favourite Git Commit
#363Earlier quoted context omitted.
To me its beautiful, because it does what an issue tracking system does not do: it explains everything. Who, why, how, what, when. It is beautiful and simple documentation. Issue tracking typically revolves about the who, what, when - not why it happened, or how it was resolved. This is why I believe that code can never be fully self-documenting. I can't understand why the code exists from reading it. All the floofy…
I think that you are not using properly the issue tracker. You absolutely need as a bare minimum the why and the reporter of the issue. When you do a blame you can easily see the issue id and open it with 1 click to understand why that code exists and who requested the change.
But now I have to go find the issue in a completely separate system, rather than just look at the commit message.
It’s added complexity, which is something we strive to remove from our code.
Re: My Favourite Git Commit
#364I think my favorite (in terms of humor) is a commit from mpv complaining about locales and encodings. You can practically feel the committer's sheer frustration. [1] https://github.com/mpv-player/mpv/commit/1e70e82baa9193f6f02...
Final paragraph: > All in all, I believe this proves that software developers as a whole and as a culture produce worse results than drug addicted butt fucked monkeys randomly hacking on typewriters while inhaling the fumes of a radioactive dumpster fire fueled by chinese platsic toys for children and Elton John/Justin Bieber crossover CDs for all eternity. I also nominate this commit.
Also from the commit message:
> like Shift JIS (sometimes called SHIT JIZZ)
Back then when I was working for a Japanese outsourced project, the code won't compile unless the computer's locale was set to Japanese because the C code had comments in Shift JIS.
Re: My Favourite Git Commit
#365I 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…
Formatted for my fellow HN-disenfranchised mobile sufferers: 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 something; e.g. create a feature flag. Stop = End d…
Wonderful. Thanks.
Re: My Favourite Git Commit
#366For 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 recently added a Rake task to one of our builds which checks for the exact problem mentioned in GP, after having 3 separate occasions in the last 6 months where OSX "smart" characters have changed the encoding of a file consumed by things expecting pure ascii.
Unfortunately it is a bit of a hack that shells out to "file -i", but I'll take it over hours of frustration.
Re: My Favourite Git Commit
#367I 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
I find that awful, because now half your subject line is burned by completely useless information: the JIRA ticket number doesn't provide any useful information when reading a git log / summary.
Re: My Favourite Git Commit
#368Earlier quoted context omitted.
Yes. As is convention, commit messages should be a one line header, then and empty line an a body (if necessary). The whole thing should be width limited to 80 or 100 characters. And the subject line should complete the sentence "If this commit is applied, it will...". It should start with a capital letter, then move to lowercase, and necessarily will start with a verb.
Is the "subject line" the same as the "header" in this schema?
Yeah, first line, w/e
Re: My Favourite Git Commit
#369Earlier quoted context omitted.
I didn't say anything about git. I said the commit messages are eternal, and none of those changes will change the commit messages (except, perhaps, changing the VCS, but usually that will preserve commit messages too).
You'd be foolish to do a VCS migration that discards the commit messages. I've never seen it happen personally, as people tend not to be that foolish. I've worked with legacy codebases that went from CVS -> SVN -> git and all of the commit messages going back to the very beginning are intact, because why would you ever do a migration that doesn't maintain them?
[deleted]
Re: My Favourite Git Commit
#370I really like Google's guidelines for commit messages because they enforce a style like this. It really makes dealing with legacy code much easier when you can look at past commits and see that your predecessors were thinking.
https://google.github.io/eng-practices/review/developer/cl-d...