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

391–400 of 406 posts

Re: My favourite Git commit (2019)

#391

Post by ickyforce »

arccy wrote: post #187
ickyforce wrote: post #154

Earlier quoted context omitted.

In my opinion PR/changeset description is exactly what should be in the commit description. In cases were we had 1 commit per PR (i.e. squashing before merging) just copying the PR description into merge commit worked really well - the goal for a PR description and a commit is essentially the same. I wish github allowed to make the copying automatic and ensure that it happens (it doesn't, unfortunately). If someone w…

settings > allow squash merging > default commit message > pull request title and description

Oh, nice, thanks. I haven't been using github recently, it looks like this option was added ~1.5y ago.

Re: My favourite Git commit (2019)

#392

Post by boolemancer »

WalterBright wrote: post #279
boolemancer wrote: post #106

Earlier quoted context omitted.

> 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. Should a cyrillic `а` and a latin `a` have the same code point? If they did then there's no consistent way to group those two alphabets, one or the other would end up with letters outside it's main grouping. And what happens…

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

> If it actually looks different, then it becomes a different code point.

Which language gets the original code point and which one needs to change?

And what happens to all of the existing text written with the original code point?

Re: My favourite Git commit (2019)

#393

Post by macspoofing »

GreenWatermelon wrote: post #379
macspoofing wrote: post #162

It's not a great git commit. 1) For all that text, the first line "Convert template to US-ASCII to fix error" - could be better. Maybe a couple of extra words to state what whitespace character caused the error, and what the error was. That comment plus the diff is all the context you need. 2) Honestly, everything else is kind of pointless. It doesn't hurt, but there's not a lot of value here. The author documented t…

People who like to learn and improve as programmers do care. In fact, the article explains the value of all that additional stuff which implies there are those who DO care. The article even provides a link to a search result showing multiple commits from people who learned from the fix. That commit message is a treasure trove of knowledge.

Outside of the small caveat that his first line could be better (which is what all future engineers will read while scanning commit messages), like I said, at worst, it doesn't hurt.

I like this level of detail, whether it is at the commit, PR, or ticket level. If one of my guys did this same write-up for this same problem, especially one of my junior guys, I would have patted them on the back and told them they did a great job - because you wouldn't want to discourage them from doing more of this kind of write-up in the future.

But here, we can be a little bit more honest, and the truth is, that the problem he solved was trivial, so this kind of detail is overkill for that problem. Once find that the config file has unprintable non-ascii character, immediately you know most parsers would blow chunks on that - and there is only one fix - remove the problem character. So succinctly tell me the error you saw, tell me the character, and if you know tell me HOW it got in there (which is probably the most important detail that isn't in the write-up so this could be prevented in the future) - and that's enough because if in the future another engineer does a ticket/commit search for this error in our bug tracker, hopefully these details will show up immediately.

Re: My favourite Git commit (2019)

#394

Post by ajuc »

kaashif wrote: post #386
ajuc wrote: post #220

Earlier quoted context omitted.

> a hellish experience. It's literally 1 click away. Or even just a hover over the margin. > The place for comments explaining why the code is needed is right next to the code! On an adjacent line! And then you refactor the code (from another place) and the function name and parameters change but the comments in adjacent lines remain the same. Ups, the comments lie. After enough time passes it's 50-50 whether a parti…

I'm not saying using git blame is hellish, I'm saying always needing to do it because of all of the things you described sounds hellish. The original comment was that you should always do it, for every line of code.

Well you should. It costs almost nothing and it can have very high positive impact.

Re: My favourite Git commit (2019)

#395

Post by kristjansson »

yencabulator wrote: post #303
mbork_pl wrote: post #54

Earlier quoted context omitted.

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.

Computers exist to represent, transmit, and display _human_ communications. If a computer system cannot represent a human utterance we should extend the representational capacity of the computer system, not force the human to conform to the limitations of the technology.

Re: My favourite Git commit (2019)

#396

Post by yencabulator »

kristjansson wrote: post #395
yencabulator wrote: post #303

Earlier quoted context omitted.

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

Computers exist to represent, transmit, and display _human_ communications. If a computer system cannot represent a human utterance we should extend the representational capacity of the computer system, not force the human to conform to the limitations of the technology.

I'm also all for eliminating overly complicated typographical conventions from places where they are technologically possible.

Re: My favourite Git commit (2019)

#397

Post by account42 »

bee_rider wrote: post #147
schacon wrote: post #94

Earlier quoted context omitted.

I can't tell if this is engaging with trolls or not, but I can't imagine that all of your interactions with your codebase are via `git log` with no other flags. Even the with the normal Git CLI that most of us use daily, most of us use `--oneline` or whatever to simplify useful calculations and visualizations like `--graph`, etc. But we're talking here mostly about code archeology, learning about the history of a blo…

Is it possible that you’ve been hit by https://xkcd.com/2501/ ? git log | less /whatever Works OK for those of us who don’t know any git flags.

Why an explicit `| less`? Git already uses a pager by default.

Re: My favourite Git commit (2019)

#398

Post by account42 »

kristjansson wrote: post #395
yencabulator wrote: post #303

Earlier quoted context omitted.

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

Computers exist to represent, transmit, and display _human_ communications. If a computer system cannot represent a human utterance we should extend the representational capacity of the computer system, not force the human to conform to the limitations of the technology.

Computers also generally don't support scribbles in the margins of your document. Or stylized glyph variants except a few that have been grandfathered in, e.g. ꙮ. Neither does the computer support whatever ligatures you might make up on the spot.

One thing that makes computers more powerful than analog tools is that they are much much much more structured.

So while we should not take computer limits for granted I think that the opposite extreme is just as if not even more absurd.

Re: My favourite Git commit (2019)

#399

Post by account42 »

mbork_pl wrote: post #353
yencabulator wrote: post #303

Earlier quoted context omitted.

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

It would be quite sad. Besides, it is not an arbitrary convention, it serves a purpose.

No it doesn't. Unbalanced quotation marks are a crime against humanity.

Re: My favourite Git commit (2019)

#400

Post by account42 »

atahanacar wrote: post #28
kristjansson wrote: post #11

Earlier quoted context omitted.

Typographic quotes are left- and right-handed, vs. the ASCII double quote which is just a single character: “quoted” "quoted" Who in the blazing highs of techno-utopianism fervor thought it was a good idea to automatically translate the latter to the former we'll never know.

Why not stylize it as typographic but store it as a "regular" double quote though?

One problem with that is that the correct start/end quotes to use depend on language which is not always know for all text snippets.
Post reply on HN