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

111–120 of 406 posts

Re: My favourite Git commit (2019)

#111

Post by hoherd »

krmbzds wrote: post #90

I would just go with "Remove non-breaking space characters" instead of writing a Russian novel. Also, if you're on macOS just use a Karabiner rule [0] that converts all non-breaking space characters to regular space characters to prevent yourself from accidentally typing it out. [0] https://ke-complex-modifications.pqrs.org/#nonbreaking_space

There are also pre-commit hooks to remove the character, even one listed on the pre-commit site. This type of hook has saved me on many occasions, and would have saved my coworkers if they used pre-commit.

https://pre-commit.com/hooks.html

Re: My favourite Git commit (2019)

#112

Post by nextaccountic »

rpsw wrote: post #27

Overall agree with the sentiment, but I would add a more specific Bottom Line Up Front (BLUF) such as: "Fix test issues caused by non-breaking space character \xa0". Tells me exactly what the problem was straight away, but I'm still free to choose to read more if I want to know more.

I love this concept. I always begin messages with the most actionable or important thing at the top, and the rest that follows is the context. Respect the time of others and don't bury the lede

Re: My favourite Git commit (2019)

#113

Post by josephg »

Sohcahtoa82 wrote: post #84
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…

> it never ceases to surprise me how often developer complaints stem from developers just not doing their damn job. One thing I learned is that any forum that appeals to software engineers will appeal to software engineers of all skill levels , from the guy that did a 6 week coding camp because he heard SWEs make a lot of money but didn't really learn anything but thinks he's an expert now, to geniuses with 10+ years…

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.

It doesn’t help that we all think of ourselves as programmers, even though people in our industry have a wide range of jobs. Someone working at a feature factory banging out websites and mobile apps has a very different job from someone slowly puzzling out a new cryptography algorithm or debugging a kernel driver. You can tell they’re different jobs because excelling in those roles takes different skills. In the first case, you want to know your domain backwards, have great social skills and work consistently. In the later cases, you need deep CS knowledge, patience and insight. It’s different.

Who is this site for? What does everyone do for your job? It’s all quite unclear.

Re: My favourite Git commit (2019)

#114

Post by a_e_k »

chjj wrote: post #47

Just an aside: is there a vim syntax command to highlight weird unicode whitespace as an error? Something like: syn match unicodeWhitespace /[list of unicode whitespace]/ hi def link unicodeWhitespace Error

I wouldn't know about the Vim equivalent, but I wrote this in my Emacs config long ago:

    (defun find-non-ascii ()
      "Find and show all of the non-ascii characters."
      (interactive)
      (occur "[[:nonascii:]]"))
It has proved quite useful on occasion.

(Yes, I could just invoke Occur directly, but I can never quite remember the regexp character class and syntax here.)

Re: My favourite Git commit (2019)

#115

Post by eviks »

The uberdetailed exploration is worthy of a blog post, those are for stories! but a commit is way too obscure a spot to put it in, so it's just a waste of effort on the writer side, but also a waste of attention of the readers, a short message describing why a change in space resolved which bug where would be more efficient

Re: My favourite Git commit (2019)

#116

Post by tux1968 »

hatsix wrote: post #105
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…

Nah, first line needs to be a summary of what you changed, so that you can find the offending commit in the first place. A news article doesn't explain WHY in the headline, it explains what. In this case, the OP's first line is spot on... if you're reading through git log, you can see that this commit likely didn't change anything functional about a test, and you should move on.

Hard disagree.

There's little reason to search the text of commit messages to find out what changed. There are many git tools to find out which commits affected parts of the code you're interested in. Whereas, trying to find that in commit messages is really inefficient and relies on reading, rather than such automated tools.

The purpose of the commit message is to help our fellow humans get a higher level understanding than is available from quickly scanning the code.

Re: My favourite Git commit (2019)

#117

Post by eschneider »

ep103 wrote: post #69
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 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…

When I document, or write commit messages, I don't really _care_ if other folks will ever look at them. Documentation is a gift for future me. If something wasn't obvious to figure out, or a potential source of future problems, I want it written down, so if _I_ go looking for info, it's there.

The fact that things are now documented for other folks is just a side benefit.

Re: My favourite Git commit (2019)

#118

Post by ryandrake »

Git commit message aside, the described debug session raises a lot of questions about the crappy tooling developers rely on.

"ArgumentError: Invalid byte sequence in US-ASCII" is a terrible, hard-to-action error message. What file? What line? What byte sequence? This "let's give the user another problem to solve" style of error messages is pervasive in our tools.

Also, why does the tool even require US-ASCII as input in the first place? Are we still living in 1995?

Also, if only ASCII characters are allowed, why does the code editing tooling allow non-breaking spaces in source code? Is there a good reason for having such a character in this file? This problem could have been avoided if the editor could have been smarter or highlighted the "bad" character better.

This developer lost an hour of his life because of a cascading chain of defective tools.

Re: My favourite Git commit (2019)

#119

Post by madsbuch »

goku12 wrote: post #110
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 don't know how it's for everyone else, but I do value the body of the commits from others. It's true that I see only the subject line for most commits. But I eventually read the full body of commits I'm interested in. Honestly, it's frustrating when commit messages don't carry enough context. Sometimes that context fits in the subject line. For others, I expect an elaborate body.

On my work I make 1-15 commits a day. If I have to spend thought cycles on the commit message, that is time that goes from other productive endeavours.

I think, as the original commenter also wrote, this might be worth it in much slower paces projects that is run in another cadence / over mailing lists.

I particularly think that high paced application development do not benefit from git as documentation.

Re: My favourite Git commit (2019)

#120

Post by gorkish »

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…

Making sense of code (or any system that changes over time) vis a vis its own history is one of those things where I really think AI/ML tools can really shine. Even with relatively low quality commit messages, I can look at something that happened 15 years ago in a codebase I am familiar with, and there will probably be enough information that I can assemble the full context, even if finding some of that information is challenging or time consuming. git log, git blame, look at the other code made in the commits, read the issue descriptions, read the code reviews. It just seems like a model could slurp that up and do a decent job of giving you a couple of paragraphs about why the line of code you are staring at is the way it is.

TBH putting such a detailed writeup in the git log doesn't really have any return -- for it to ever be useful to you again, you have to know the information is there; you then have to actively seek it out, with the hope that whatever you did to make it 'searchable' is going to work for you again. I can say with surety that if I were looking at a bug similar to the one linked from this article, I would not look to the git log for inpsiring a fix; I'd just fix it. Any extra time I would take would be to understand how a UTF8 nbsp ended up where it shouldn't have been in the first place -- something that the author of this commit seemed to have no interest in doing, but which likely has greater relevance than the documentation of the fix.

I want to be clear that I support commit messages that say what they do though; I'm not advocating for -m 'fixed' shenanigans, however at the same time I believe that -m 'fixes #1234' is often enough

Post reply on HN