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

My favourite Git commit (2019)

dhwthompson.com

Post reply on HN
Print view View original

301–310 of 406 posts

Re: My favourite Git commit (2019)

#301

Post by JadeNB »

Sohcahtoa82 wrote: post #232
JadeNB wrote: post #170

Earlier quoted context omitted.

> Yep. This is one of the big problems with online communities. When someone makes a bold statement, I have no idea if they’re a grizzled engineer with grizzled, hard earned engineering opinions, or some kid fresh out of a coding bootcamp who thinks they’re all that. In person, I’d treat those two people incredibly differently. Online? It’s impossible to spot the difference. I know there are limits to this, but isn't…

True, but occasionally a newbie offers a solution to a problem and rejects the rejection when people try to tell them why their solution won't work. For example, several years ago here on HN, during a thread about cryptography, someone admitted to not knowing much about cryptography, but offered one-time pads as a solution to the weaknesses of PKI. I tried to tell them that OTP solve a different problem that is unrel…

> If I see a bold claim that I have a hard time believing, then I'll ask follow-up questions. But when someone makes a bold claim that is just factually incorrect, while admitting they don't know much, and then get upset when someone tells them why it's incorrect, then that's just plain frustrating.

But that doesn't seem a situation that would have been addressed by fixing the problem that you originally identified:

> Yep. This is one of the big problems with online communities. When someone makes a bold statement, I have no idea if they’re a grizzled engineer with grizzled, hard earned engineering opinions, or some kid fresh out of a coding bootcamp who thinks they’re all that. In person, I’d treat those two people incredibly differently. Online? It’s impossible to spot the difference.

Here, it sounds like you knew on which side of the divide a person fell. The resulting problem is still a problem, but it's one that also occurs offline!

Re: My favourite Git commit (2019)

#302

Post by simonw »

I used to write really long, essay style commit messages like this one.

Then a friend pointed out that I was effectively writing documentation and hiding it in commit messages.

Instead, I switched a lot of that effort to updating actual documentation (in a docs/ folder) that was relevant to the commit - so the commit would still have the information in it, it's just it was in an actual file and not just the commit message.

I also make sure my commits almost always link to an issue thread, as that's a great place to put all kinds of extra context around the commit that can be updated independently of the commit itself.

Re: My favourite Git commit (2019)

#303

Post by yencabulator »

mbork_pl wrote: post #54
maleldil wrote: post #35

Earlier quoted context omitted.

Render them as standard double quotes? The same way Markdown renders a single backtick as just a backtick, but text surrounded by backticks becomes code.

Nice try, but the problem with this is that typography is _really_ complex. For example, there is a rule in English typography (I'm not sure if it's often used today though) that when you have a quotation spanning several paragraphs, you should put an _opening_ quote at the beginning of each paragraph – but only one _closing_ one at the end of the quote.

We've let go of other historical typographic and spelling conventions, it's time to let go of that one too.

Re: My favourite Git commit (2019)

#304

Post by yencabulator »

thaumasiotes wrote: post #95
atahanacar wrote: post #7

Earlier quoted context omitted.

>smart quotes I never understood why a "stylistic" choice requires separate characters. If we don't need a serif and non-serif version of every character and instead leave it to the software, why can't we do the same with the "smart" quotes?

It's not a stylistic choice. Opening quotes and closing quotes are different things, and it isn't possible to tell the difference (when not already provided) without parsing the language in which they're used. That's why in TeX you have to manually specify which kind you want, and in software like Wordpress that just guesses, the guess is usually wrong and your published text looks ridiculous.

The complaint was purely about software replacing normal quotes with "smart quotes", not that it did it wrong.

Re: My favourite Git commit (2019)

#305

Post by mb7733 »

TheRealPomax wrote: post #228
mb7733 wrote: post #70

Earlier quoted context omitted.

Well, `git` is still the primary way I interact with a git repository, and `git log` shows the entire commit message by default. So I don't run into this problem. If some "modern" git frontend is only capable of displaying the first line of a commit message, then this is a problem with that tool, not git itself. (I'm also not convinced this is a limitation of all modern tooling...)

periodic reminder that `gitk` exists, and has come with git since... pretty much forever? If you're reading `git log`, you really owe it to yourself to run `gitk` at least once to see what you've been missing for over a decade now.

What gave you the impression that I haven't heard of gitk?

Re: My favourite Git commit (2019)

#306

Post by fbdab103 »

marwis wrote: post #175
winwhiz wrote: post #151

Earlier quoted context omitted.

Really simple answer: Repeatability. I am not saying it is the only one right blessed answer, but if you really want to know why people haven't moved to pure GUI interfaces, imagine describing to someone how to add a new directory to their path. fleet $HOME/.config/fish.config # ADD this line somewhere set -x PATH /opt/git/bin $PATH Or: 1. Either hit WINDOWS-E and right click on This PC and select properties (it migh…

On Windows it's actually just: 1. Press Win key 2. Type env 3. Choose system or account

It's even better because thanks to the Start Menu randomization process either could appear first in the results. Sometimes they will switch position after being presented.

Re: My favourite Git commit (2019)

#307

Post by c0pium »

bastardoperator wrote: post #291
c0pium wrote: post #262

Earlier quoted context omitted.

Because you don’t actually understand the subtleties of the side effects of that 40-character change and building intuition about it takes a paragraph. It’s all fun and games until your codebase is >1,000,000 loc.

This code never worked but made it into production. What I see is a developer hucking garbage over the wall, not testing their own code, passing reviews assuming they exist, and eventually stopping the train in its tracks because they're more concerned with pretty commit messages. I also think this is beyond simple to catch early be it the editor, the pre-commit hook, or any other range of tools that could have and s…

> Does this mean I'm cool enough to be in your club?

If you have to ask, then the answer is no. I don’t make the rules.

Re: My favourite Git commit (2019)

#308

Post by WalterBright »

dullcrisp wrote: post #296
WalterBright wrote: post #279

Earlier quoted context omitted.

> Should a cyrillic `а` and a latin `a` have the same code point? Yes. Consider a book. Can you tell if it's a cyrillic or a latin `a`? Of course you can, because of the context. Unicode is about visible text, having hidden semantic meaning makes it something else. Besides, 'a' can have all kinds of semantic meanings - all depending on the context in which they are used. There is no way to encode all this into Unicod…

How about an l and an I? Or a closed "a" and one with the little handle? A zero with a stroke, a zero without a stroke, and an O? I can see where you're coming from, but deduplicating every glyph from every culture based on which do or don't generally look the same when printed sounds like a tall order. And if all you want to record is the shape, you can use a PNG with OCR and bypass Unicode entirely.

> How about an l and an I? Or a closed "a" and one with the little handle? A zero with a stroke, a zero without a stroke, and an O?

Those are font differences, not character differences. (Unicode has also failed by adding in some fonts. The nuttiness never ends.)

Re: My favourite Git commit (2019)

#309

Post by WalterBright »

tomjakubowski wrote: post #300
WalterBright wrote: post #279

Earlier quoted context omitted.

> Should a cyrillic `а` and a latin `a` have the same code point? Yes. Consider a book. Can you tell if it's a cyrillic or a latin `a`? Of course you can, because of the context. Unicode is about visible text, having hidden semantic meaning makes it something else. Besides, 'a' can have all kinds of semantic meanings - all depending on the context in which they are used. There is no way to encode all this into Unicod…

How does your scheme handle Turkish "Dotless I"? Should there be different codepoints for serif and sans-serif versions of the same letter? After all, in some typefaces, "uppercase I" and "lowercase L" look just about the same.

I think you mean fonts. No, Unicode should not encode fonts.

Nor should it encode italic, boldface, underline, line out, reverse video, point size, superscript, subscript, or colored. Those are all style attributes, best applied with a style sheet, not a code point.

Re: My favourite Git commit (2019)

#310

Post by WalterBright »

kelnos wrote: post #186
WalterBright wrote: post #36

At the DLF, our pull requests are usually accompanied by a link to the bugzilla entry, which usually have a detailed explanation. P.S. Having multiple Unicode values that exhibit identically when displayed are a huge veer-into-the-ditch mistake. I.e. the notion that code points should have semantic value is simply wrong.

> our pull requests are usually accompanied by a link to the bugzilla entry, which usually have a detailed explanation. This practice annoys me quite a bit, actually. Well, if there is a bug tracker issue, of course, definitely link to it in the commit message. But that should provide extra, optional information; everything I reasonably need to understand the change should still be in the commit message. I don't want…

I see your point. We are migrating to using github issues for that and related reasons.
Post reply on HN