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

271–280 of 406 posts

Re: My favourite Git commit (2019)

#271

Post by mtrower »

qez2 wrote: post #134
ep103 wrote: post #69

Earlier quoted context omitted.

I know the OP didn't mean it this way, but after reading HackerNews for the last decade or whatnot, it never ceases to surprise me how often developer complaints stem from developers just not doing their damn job. "Almost nobody ever sees it.... nobody reads anything other than the first 50 chars of the headline." On the one hand, I get it. If a tool makes something difficult, people are less likely to do it, and as…

> If they didn't write a git commit message because "no one is going to read it anyway", they're a lazy engineer. If an engineer spends an hour writing a commit message that no one reads, that's an unproductive engineer, compared to where they should be. I have to admit, I am lazy. I don't spread seeds by hand; I use a tractor. I don't swim across the ocean; I use an air plane. Likewise, I don't write documentation i…

> If an engineer spends an hour writing a commit message that no one reads, that's an unproductive engineer, compared to where they should be.

Okay, maybe don't spend an hour. It would take a special kind of commit to need more than a few minutes writing a decent commit message.

> And I would argue we shouldn't cater to developers who make documentation difficult to access for everyone else by hiding it where only crappy tools can reach it.

Yeah. Like web browsers. And PDF viewers.

The non-caustic point here is that clearly different people have different ideas about what is accessible.

Re: My favourite Git commit (2019)

#272

Post by ParetoOptimal »

palata wrote: post #250
schacon wrote: post #61

For better or worse, my experience as a GitHub cofounder and author of several Git books (Pro Git, etc) is that the Git commit message is a unique vector for code documentation that is highly sub-optimal. The main issue is that most of the tooling (in Git or GitHub or whatever) generally only shows the first line. So in the case of this commit example would be the very simple message of a generic "US-ASCII error" pro…

> The main issue is that most of the tooling (in Git or GitHub or whatever) generally only shows the first line. Maybe I do it wrong, but the most basic interface I use to check the git history is `git log`, which shows the whole commit message. GitHub takes me 18 clicks to find the commits, I don't see why I would even bother using it.

Many engineers primarily or even exclusively use git via githubs interface and have never made a commit with a body.

Re: My favourite Git commit (2019)

#273

Post by cerved »

neilkk wrote: post #208
js2 wrote: post #107

Earlier quoted context omitted.

As someone who has contributed to Git since before GitHub existed and who maintains legacy code, I simply cannot disagree more. I use `git blame`, `git log`, and `git show` in the terminal all the time. It's trivial to follow the history of a file. It takes me seconds to use `git log -G` to find when something was added or removed. Nothing pains me more than to track down the commit and then find a commit message tha…

The thing is that writing a good commit message for future people doing `git blame` is only worth it if it's a line of code which someone in the future will look at and need to know why it was changed from its previous form to the current form. If you simply want to comment the current state of the code, you should add a comment in the code. No one will ever need to know in the future why that particular space charac…

The example in the blog post would be a much better example if some kind of test or linting step was added to catch these white-space errors, to explain the need for catching such errors.

Pro tip, you can write both comments and commit messages.

Re: My favourite Git commit (2019)

#274

Post by ParetoOptimal »

lisper wrote: post #157
schacon wrote: post #61

For better or worse, my experience as a GitHub cofounder and author of several Git books (Pro Git, etc) is that the Git commit message is a unique vector for code documentation that is highly sub-optimal. The main issue is that most of the tooling (in Git or GitHub or whatever) generally only shows the first line. So in the case of this commit example would be the very simple message of a generic "US-ASCII error" pro…

> The main issue is that most of the tooling ... generally only shows the first line. > I don't know exactly what the answer is Isn't it obvious? Write better tools. There is no reason you have to be stuck with the deficiencies of what someone else has built. That's the whole point of open-source software. It's more than a little concerning that a "GitHub cofounder and author of several Git books" has to have this po…

>There is no reason you have to be stuck with the deficiencies of what someone else has built.

There is a concerning trend of "we only use vscode" and popular preference shifting to "adjust to popular tool" rather than "use best tool".

This means sadly things like GitHub start to define git even more for your coworkers.

Re: My favourite Git commit (2019)

#275

Post by cerved »

ParetoOptimal wrote: post #272
palata wrote: post #250

Earlier quoted context omitted.

> The main issue is that most of the tooling (in Git or GitHub or whatever) generally only shows the first line. Maybe I do it wrong, but the most basic interface I use to check the git history is `git log`, which shows the whole commit message. GitHub takes me 18 clicks to find the commits, I don't see why I would even bother using it.

Many engineers primarily or even exclusively use git via githubs interface and have never made a commit with a body.

Those "engineers" go on _The List_

Re: My favourite Git commit (2019)

#276

Post by dgunay »

I put less importance on commit messages being thorough, though I do admire when people write detailed information in the body. What's more important to me is to have good commit hygiene. It's something the industry is also generally terrible at, but has slightly more immediate value. For example, if your PRs have clean, atomic commits that can stand on their own, I can "rescue" chunks of useful functionality from review hell by cherry picking them out. I do this several times a month to help my teammates burn down huge PRs or take good ideas out of doomed branches.

Re: My favourite Git commit (2019)

#277

Post by cerved »

twosdai wrote: post #211
schacon wrote: post #61

For better or worse, my experience as a GitHub cofounder and author of several Git books (Pro Git, etc) is that the Git commit message is a unique vector for code documentation that is highly sub-optimal. The main issue is that most of the tooling (in Git or GitHub or whatever) generally only shows the first line. So in the case of this commit example would be the very simple message of a generic "US-ASCII error" pro…

Completely agree, the value with the message is really just to link an external ticket Id, the user experience is much better in external ticketing systems for all of the story telling that the article loves. Don't read "external ticket system" as closed either, plenty systems are open to the public.

Right. The massive commit with minimal description and a PR number which I can look up in Azure DevOps to find a review with no description, no discussion and a mention of a number I can go and look up in Jira, where some Scrum master wrote half a sentence of what needs to be done and asking to "reach out to Jeff" for explanation.

So much more valuable and great user experience

Re: My favourite Git commit (2019)

#278

Post by cerved »

dgunay wrote: post #276

I put less importance on commit messages being thorough, though I do admire when people write detailed information in the body. What's more important to me is to have good commit hygiene. It's something the industry is also generally terrible at, but has slightly more immediate value. For example, if your PRs have clean, atomic commits that can stand on their own, I can "rescue" chunks of useful functionality from re…

Agreed. I'll settle for good commit hygiene over good commit messages.

It often seems a tough ask to have both

Re: My favourite Git commit (2019)

#279

Post by WalterBright »

boolemancer wrote: post #106
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.

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

> If they did then there's no consistent way to group those two alphabets

Doesn't matter.

> And what happens if the shapes of those two characters divege over time?

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

> There are characters in Chinese and Japanese that share a code point but the shapes of the characters aren't the same in the two languages

More evidence that the Unicode committee lost its way.

Think of it this way. Printing Unicode text on a piece of paper, and then OCRing it back into Unicode, should be a lossless operation. Or another way - anyone should be able to tell what the code point value is by looking at the visual representation of it.

Re: My favourite Git commit (2019)

#280

Post by thfuran »

neilkk wrote: post #253
tehnub wrote: post #238

Earlier quoted context omitted.

The thing is that writing a good commit message for future people doing `git blame` is only worth it if it's a line of code which someone in the future will look at and need to know why it was changed from its previous form to the current form. Well what about this example: I removed a few lines of code and explained in the commit message why I thought it was correct to do that. If somebody (possibly me) comes lookin…

Right. You've given an example of exactly what I said was the only reasonable use case for detailed info in the commit message: someone in the future will need to know the history of that particular piece of code. It seems like the point of your specific example is to say 'in some cases you might want to know the history of a gap '. Fine. That seems like a nitpick to me. No one in the future will need to know the his…

But virtually every diff is one that someone in the future might want more information on. You can't know that they won't until you get to the end of the future and haven't needed it.
Post reply on HN