Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

My Favourite Git Commit

fatbusinessman.com

Post reply on HN
Print view View original

201–210 of 389 posts

Re: My Favourite Git Commit

#201

Post by mattacular »

jordigh wrote: post #168
strictfp wrote: post #30

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. Why not? Where else do you want it? Is something forcing you to read the full commit log? There's no length limit on commit messages and commit messages are mostly out of the way. Most VCSes have a way to only show you the first line. So if you want summaries, that's what the first line is for. If you want the full story, that's what the body is for. Combined wi…

The pull request is a good place to put such a large amount of information. That would also be a good way to make sure it is seen by the broader team instead of burying it in commit history. You could make the argument that then it would not be part of the git history and therefore could be lost if you change hosts.

Re: My Favourite Git Commit

#202

Post by simias »

powjfjti83 wrote: post #170

To an extent I find this lazy and even a humorous take is giving it attention it doesn’t deserve I can complain about anything Can this person build a language that’s still as broadly useful as C that no programmer will find issue with “Oh boy I encountered a particular odd and annoying thing. I won’t bother to offer an alternative. I’ll just complain about others efforts while ignoring they ultimately enabled me to…

The commit was complaining specifically about the way locales were designed, not C as a whole. While C was very successful, I don't think you could argue that C locales ever reached the same level of popularity.

That being said I do agree with you that this complaining is not massively productive. Dealing with localization and non-ASCII text is notoriously difficult. Look at Java, Python 3, Windows, PHP 6 and how many "misconceptions about Unicode" articles you can find online. You could spend hours pointing out how each approach has tons of drawbacks but clearly the perfect solution doesn't seem to exist so a compromise had to be found.

In particular I'm not sure I agree with his complaints about locales being global state. How else would you handle them? You need to have some kind of global config flag somewhere to decide what local the user wants to use. Having explicit versions of the stdlib taking locales as parameters could be nice I suppose.

This bit in particular seems to completely miss the point:

>Idiotically, locales were not just used to define the current character encoding, but the concept was used for a whole lot of things, like e. g. whether numbers should use "," or "." as decimal separaror.

Of course if this programmer assumes that locales and charsets should be the same thing they'll end up frustrated.

Re: My Favourite Git Commit

#203

Post by jordigh »

mattacular wrote: post #201
jordigh wrote: post #168

Earlier quoted context omitted.

> I don't want your entire life story in my commit log. Why not? Where else do you want it? Is something forcing you to read the full commit log? There's no length limit on commit messages and commit messages are mostly out of the way. Most VCSes have a way to only show you the first line. So if you want summaries, that's what the first line is for. If you want the full story, that's what the body is for. Combined wi…

The pull request is a good place to put such a large amount of information. That would also be a good way to make sure it is seen by the broader team instead of burying it in commit history. You could make the argument that then it would not be part of the git history and therefore could be lost if you change hosts.

I will make that argument. The hosting is ephemeral, the commit message is eternal.

Plus, what if you want to know what happened and you're simply offline? Let's not unnecessarily break the D in DVCS.

Re: My Favourite Git Commit

#204

Post by rpmisms »

jplayer01 wrote: post #107
beefhash wrote: post #101

I 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.

Pure, rage-filled, git commits are possibly the most honest form of art.

Re: My Favourite Git Commit

#205

Post by wool_gather »

deividy wrote: post #136
ShteiLoups wrote: post #130

Earlier 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.

"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.

Re: My Favourite Git Commit

#206

Post by woodrowbarlow »

magashna wrote: post #157
jplayer01 wrote: post #135

Earlier quoted context omitted.

> But maybe a better question is: “What are we going to do with these detectors now that we have them?” A lot of the people doing this research are at Google and Facebook.I guess at least we know the technology is in good hands and definitely won’t be used to harvest your personal information and sell it to.... wait, you’re saying that’s exactly what it will be used for?? Oh. > Well the other people heavily funding v…

That resume is something else.

i'm all for adding an artistic flare to set your resume apart from others... but that's a bold move, cotton.

Re: My Favourite Git Commit

#207

Post by luord »

What I gather from this is that commit messages are a better place for documenting stuff like this than polluting every line of code with often redundant comments.

I like it.

Re: My Favourite Git Commit

#208

Post by sethammons »

luord wrote: post #207

What I gather from this is that commit messages are a better place for documenting stuff like this than polluting every line of code with often redundant comments. I like it.

I think the git log is an interesting place to document this kind of thing. Also, there should never be redundant comments. I do think though that lots of folks put things in the git log that _should_ be a code comment. For myself (as most of the people I can think of that I work with), we don't reference git commits unless we are actively investigating a previous change. You should not hide reasons for code being the way it is in the git commit; it should be exposed for direct observation to someone who might edit the code. Ex: '// the following delete call is required to remove the item from the DNS cache to ensure the test validates non cached dns items'. That should be in the code.

Re: My Favourite Git Commit

#209

Post by balabaster »

mikehollinger wrote: post #125
beefhash wrote: post #101

I 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...

My favorite (in terms of dark humor, if we’re honest) is YOLO, one of the more interesting deep learning object detectors. [1] It is the exact opposite of yours in every way. The code is brilliant however. Even the papers are snarky. [2] [1] https://github.com/pjreddie/darknet/commits/master [2] https://arxiv.org/pdf/1804.02767.pdf

Number 2 might be the greatest technical paper I've ever read. Brilliant :D

Re: My Favourite Git Commit

#210

Post by tom_mellior »

ShteiLoups wrote: post #130
navinsylvester wrote: post #108

I 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…

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.

> And the subject line should complete the sentence "If this commit is applied, it will...".

I kind of do it like this. Others use subjects that complete the sentence "This commit...", so their subjects will start with "adds", "fixes", etc. Though that adds one or two extra characters!

Post reply on HN