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

291–300 of 406 posts

Re: My favourite Git commit (2019)

#291

Post by bastardoperator »

c0pium wrote: post #262
bastardoperator wrote: post #179

Earlier quoted context omitted.

Why would I waste time reading this paragraphs long commit message when I can look at a diff and a 40 character headline and completely understand the issue? You think it's lazy, I think this is wasteful. Personally I don't need an epic story about making a one character change because your editor isn't configured to catch gremlins... it's just not that interesting.

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 should have prevented this.

I'm not saying a detailed commit message is never warranted, I'm saying this fuck up doesn't warrant a short story let alone a prize for being overly verbose. BTW, I did a loc . on the repo I work in, came back with 7400000 lines of code. Does this mean I'm cool enough to be in your club?

Re: My favourite Git commit (2019)

#292

Post by yencabulator »

cerved wrote: post #277
twosdai wrote: post #211

Earlier quoted context omitted.

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

Just wait till next year when your employer migrates away from Azure DevOps and that PR number will be a dangling link forever lost.

Re: My favourite Git commit (2019)

#293

Post by yencabulator »

jeremyw wrote: post #172
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…

I take Scott's point with a difference perspective. Though commit messages are ephemeral and hard to utilize in the future, they're the stream of consciousness of the project. They convey very important shifts in direction, discoveries in the making, code smells, limits of current architecture, and markers of tech debt. We don't know what this beast will be. And we figure it out commit by commit. Document it.

Commit messages are the very opposite of ephemeral; they are the longest-lasting history a project is likely to have!

Re: My favourite Git commit (2019)

#294

Post by makeitdouble »

krobelus wrote: post #230
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 problem is that Git was built so that the commit message is the _email body_, meant to be read by everyone in the project. I find this very hard to believe. Isn't it "everyone who is interested in the commit subject/files touched should read the body". Why would anyone else read immutable historical documentation? > Even if you're _very good_ at Git, finding the correct invocation of "git blame" (is it "-w…

I might be in the minority, but parent's comment is probably about people like me: most of my coworkers have context free, or at best succinct commit messages. I never read more than the first line listed in the commit list, and don't even assume the description is always accurate.

Instead I'll spend my time stalking the related merge request, where the full description of the whole change resides, with probably a link to the ticket or reference documentation, and all the back and forth on why something is or isn't a good idea.

I think the world could be a better place if all of that was in git directly, but that's also utting much more burden on an already complex tool.

Re: My favourite Git commit (2019)

#295

Post by ycombobreaker »

fl0ki wrote: post #158
bee_rider wrote: post #147

Earlier quoted context omitted.

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.

The only sets of arguments I use to git log regularly: * `git log branch` because I want to cherrypick or checkout parts of another branch. * `git log --stat` because what files changed can be a big clue for what I'm looking for. * `git log -- dir1/ file1/` because I only care about commits to a certain part of the tree. Other than that, `git log` already provides so much information to /search or even `grep` through…

A rebase to clean up your branch is great, and I lean on my team to do this. Unfortunately it's impossible to automate, because it amounts to craftsmanship. I've seen larger teams fall back to squash-merging, which at least discards checkpoint/broken/WIP commits. But it loses the nuance of more complex changes performed in logical stages.

Re: My favourite Git commit (2019)

#296

Post by dullcrisp »

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…

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.

Re: My favourite Git commit (2019)

#297

Post by GuB-42 »

kelnos wrote: post #195
GuB-42 wrote: post #129

Earlier quoted context omitted.

You also get what is changing by doing "git diff", and often, it is self explanatory, especially if you have already commented in code why you did what you did. For example: - code: MAX_SIZE=1024 // maximum size the backend supports - commit: limit the size to 1024, as it is the maximum the backend supports - jira: fixed the problem by limiting the size to 1024, as it is the maximum the backend supports - confluence:…

I'm generally wary of code comments. They tend to rot; people change the code around them but then forget to update the comments. They also take up valuable screen real estate. I'd mostly rather be reading code than comments, and I can see more context when there are fewer comments. If a comment truly is necessary, it should explain why the code is doing something tricky, unusual, or unexpected. In your particular ex…

I am generally on the same opinion as you are. I dislike superfluous comments and documentation. In fact, I usually try not to read these as these can be deceiving.

But this is one of the few cases where I think comments are worthwhile. That is, as an out-of-band channel where you explain things that are not in the code base, that is not common knowledge to skilled programmers, and that is hard to express in other ways.

This is a simplified example, normally, one would say more than that. Something like "for historical reasons, the backend is configured with a size limit of 1024, larger messages may be dropped". This value may be the result of a conversation with someone from the backend team, and without this comment, a newcomer will have absolutely no idea about the why, even if his is a programming god. And there is no easy way to express that in code. "MAX_SUPPORTED_SIZE" without any context may be insufficient, as it may raise questions about why this limitation even though the software used for the backend shouldn't have this limit.

I don't think the value of comments is only on the trickiness of the code. Some code like bit twiddling hacks may be tricky, but these are the kind of things good programmers should know, or if they don't, learn. There are publicly available resources for that. But parts, even simple parts, that require domain knowledge, or worse, knowing specific people in the company definitely benefit from comments if code can't express it.

Re: My favourite Git commit (2019)

#298

Post by gumby »

palata wrote: post #255
gumby wrote: post #64

That first line of the commit message is most important so that `git log` can address chesterton's fence. And IMHO in this case the committer whiffed. The key is not to put what you did in that first line, but why . Anyone interested in what can just look at the code, perhaps via a diff. So something like "nginx .conf files must be in us-ascii" Then "changed blahblah.erb to remove nonbreaking space character" Then th…

> The key is not to put what you did in that first line, but why. Can't we just say that the key is to put something that makes sense for the first line, given that sometimes only the first line is printed? I don't really care if it says "The files must be in us-ascii" or "Changed the files to us-ascii"... both of them clearly tell me that the files were changed to us-ascii.

The difference is Chesterton's fence: when you encounter something seemingly pointless you should learn why it was there before you consider removing or changing it.

Re: My favourite Git commit (2019)

#299

Post by wharvle »

kaashif wrote: post #201
ajuc wrote: post #43

Earlier quoted context omitted.

If you change a line of code without doing git-blame on it first you're doing it wrong. I've been bitten by this many times - I change obvious bug, I'm about to commit the changes, I see the previous commit which introduced the "bug" on purpose and the attached JIRA task has perfectly good explanation for why my obvious change would have reintroduced some bug from 2 years ago :)

> If you change a line of code without doing git-blame on it first you're doing it wrong. Working on a project where this is necessary sounds like a hellish experience. The place for comments explaining why the code is needed is right next to the code! On an adjacent line!

Hard concur. When something might look wrong or misleading to a future reader is exactly the time to comment.

Re: My favourite Git commit (2019)

#300

Post by tomjakubowski »

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…

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.

Post reply on HN