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

301–310 of 389 posts

Re: My Favourite Git Commit

#301

Post by mcgwiz »

Some of this background decision-making information can be included as developer documentation, whatever form that takes, e.g. as comments (usually for low-level) or sibling README file (usually higher-level).

Commit logs will have the greatest detail, but they also are the costliest to dig up, often requiring multiple rounds of `blame`. They are therefore most appropriate to include information pertinent at integration-time, namely code review context/justifications.

Merge commits (such as those created during typical PR/MR merges) have similar potential to include explanatory background, but at a coarser granularity, e.g. feature level.

Re: My Favourite Git Commit

#302

Post by toastal »

gus_massa wrote: post #84
leejo wrote: post #45

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

I prefer that the commit includes the addition of a test in the test suit that get fixed (or a few). This is good because: * It ensure that the bug is real. [1] * It ensures that the bug is fixed. [1] * It prevents reversions (assuming the test are run automatically). * The test may prevent reversions in other related code, or discover other hidden bugs. * It brings you closer to a 100% test coverage. * You don't hav…

100% test coverage is such an overrated stat.

Re: My Favourite Git Commit

#304

Post by slrz »

mark-r wrote: post #252
ska wrote: post #248

Earlier quoted context omitted.

Sure, it's easy to use. But that isn't the job of standardization bodies, or the right test to use on something as low level as this. It's harder to get right, but it is exactly these sort of failures in standardization that cause the most global pain, because they wend their way through everything.

In this case I don't think the locale functions were designed by committee, I think they were accepted as-is from a popular implementation. And they were implemented that way because it was the simplest most straight-forward way (I'll admit I'm just guessing now). Were they part of K&R C?

No, of course not.

Re: My Favourite Git Commit

#305

Post by jburgess777 »

btilly wrote: post #243
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...

Oh. Locales. The remembered pain. Save a file in Notepad. Open in vi. See that it is different. Find data in the database, no clue the weird characters were originally supposed to be. And so on and so forth. I once wrote a reasonable program and sent it as a bug report to the maintainer of the Perl module DBD::File. He sent it as a bug report to BerkeleyDB. They said they never thought about it but yes, that would be…

Bugs in the C library string localisation have previously caused a problem in PostgreSQL as well:

https://wiki.postgresql.org/wiki/Abbreviated_keys_glibc_issu...

Since Postgres 10 they use ICU instead of relying on the C library string routines to give more control.

https://www.2ndquadrant.com/en/blog/icu-support-postgresql-1...

Re: My Favourite Git Commit

#306

Post by a_e_k »

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

> 4. Things We Tried That Didn’t Work

I love seeing a section like this when reviewing a paper. I really wish more authors would include one. (Goodness knows I've chased down enough dead-ends in some of my own research efforts.)

Re: My Favourite Git Commit

#307

Post by shrimp_emoji »

ISO-morphism wrote: post #211
woodrowbarlow wrote: post #206

Earlier quoted context omitted.

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

It's not about trying to catch attention, it's saying "I'm so good that even though this is totally unprofessional you're still going to want me"

It's the resume equivalent of Culture ships with silly names/AI personas.

At a certain level, it's boring to just be good. The interesting challenge becomes to stay good while being silly as fuck.

And that's why I'm serious and professional.

Re: My Favourite Git Commit

#308

Post by Fnoord »

> It makes everyone a little smarter

> One thing Dan did here that I really appreciate was to document the commands he ran at each stage. This can be a great lightweight way to spread knowledge around a team. By reading this commit message, someone can learn quite a few useful tips about the Unix toolset:

> [..]

In the spirit of making everyone smarter: simplicity matters. Using the combination of find -print0 and piping that to xargs -0 is much easier than the mentioned abacadabra of characters.

From the xargs(1) manual:

> The options are as follows:

> -0 Change xargs to expect NUL (``\0'') characters as separators, > instead of spaces and newlines. This is expected to be used in > concert with the -print0 function in find(1).

Re: My Favourite Git Commit

#309

Post by mark-r »

simias wrote: post #257
mark-r wrote: post #220

Earlier quoted context omitted.

When locales were invented, it was reasonable to assume that the locale would determine the character set. With the subsequent invention of Unicode that no longer needs to be the case, but code standards live forever.

>When locales were invented, it was reasonable to assume that the locale would determine the character set Sure, but that's not what the commit is saying. Instead it's saying that it should only determine the charset and that Unicode effectively makes locales pointless. That's absolutely not the case, there's a lot more to locales than character encoding.

I think we're in agreement. There are lots of aspects to a locale, and character sets are only a small part of that. Possibly the most visible part though.

Unicode doesn't make character sets pointless, it only makes them deprecated. It's still useful to have a way to convert from one set to another, and it's a shame the standard library doesn't have an easy way to do that. The deficiencies of locales are visible only in hindsight.

Re: My Favourite Git Commit

#310

Post by carapace »

pault wrote: post #296
computerex wrote: post #264

Earlier quoted context omitted.

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.

Try telling that to my boss, who has an autistic child. I held your opinion until I stuffed my foot in my mouth in a meeting. Now I don't use that word.

There it is.

"When you omit courtesy you're throwing sand in the gears of a machine that doesn't work too well in the first place."

~Heinlein (I'm paraphrasing.)

There's no glory in being a boor, and no shame in being courteous.

None of this is news: https://en.wikipedia.org/wiki/Etiquette#History

    A fool never learns,
    A man learns from his mistakes,
    A wise man learns from the mistakes of others.
Post reply on HN