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

161–170 of 406 posts

Re: My favourite Git commit (2019)

#161

Post by zellyn »

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…

If you follow a pull-request based workflow, and if you typically squash down to one commit, then finding these messages isn't too bad, since the commit description pre-populates into the pull request description. I often track changes down not to their commit, but to their pull request.

Granted, that's not exactly `git`, but rather `github`…

Re: My favourite Git commit (2019)

#162

Post by macspoofing »

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 their journey in tracking this bug .. who cares?

Re: My favourite Git commit (2019)

#163

Post by jonathanpglick »

madsbuch wrote: post #119
goku12 wrote: post #110

Earlier quoted context omitted.

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.

Until it's 7 years later, the original developers are gone, the ticketing system has changed twice, and you have no clue why something is the way it is.

When you're committing is exactly when you already have the context of "why" loaded and even a short explanation should be quick to write. The thought cycles argument feels lazy unless you're doing a bunch of quick exploratory commits and clean up/squash your git history later and add context once a solution solidifies.

Re: My favourite Git commit (2019)

#164

Post by lazide »

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…

Counter point - Engineering systems which require constant overriding of basic human nature therefore requiring making significant effort on the regular to avoid mistakes is bad engineering.

Re: My favourite Git commit (2019)

#165

Post by teaearlgraycold »

josephg wrote: post #113
Sohcahtoa82 wrote: post #84

Earlier quoted context omitted.

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

Once I started interviewing - mind you, interviewing candidates that already got through several filters before getting in front of me - I realized how mediocre the average engineer is. Should it then follow that the average engineering opinion online is mediocre?

Re: My favourite Git commit (2019)

#166

Post by joshuamorton »

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…

But a commit message in an arbitrary project is not where you give someone a lesson about nginx rules.

"nginx .conf files must be in us-ascii" is maybe a good bug or pull request title, but it may correspond to multiple commits that do different things, but it doesn't tell me what's happening. Is this converting a file to us-ascii, is this writing a tool to convert files to ASCII, is this updating documentation, is it creating a test, some combination? Leading with what, not why addresses that confusion.

Re: My favourite Git commit (2019)

#167

Post by nightfly »

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…

git log. git blame, grab hash, git log hash. You make it sound like some arcane magic...

Re: My favourite Git commit (2019)

#168

Post by joshuamorton »

hermitdev wrote: post #142
tux1968 wrote: post #116

Earlier quoted context omitted.

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

Totally agree with you. We already know what changed: it's the diff! We need to know why you're making the what . The message should address why the diff is necessary. Was it a bug fix? Ok, what's the bug you're fixing? What's the evidence that you think they diff addresses it? Is it a new feature? What's the requirement? I can already tell what you did by the diff, but I can't tell from the diff alone if it actually…

This is true of the overall commit message, but we're talking about the first line. If I'm browsing git-log short or whatever, I don't have the diff, I have an ordered list of commit hashes and one line summaries, and I'm trying to decide which diffs I actually want to look more closely at.

Re: My favourite Git commit (2019)

#169

Post by kelnos »

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…

While this may be how most people interact with git, I couldn't disagree more when it comes to my personal use.

I use 'git blame' (I've never needed to pass any options to it) and 'git show' liberally if I'm trying to understand a change that was made, and if the committer took the time to write a commit message body, of course I'll see it and read it.

> ... I think why people just don't care much about good commit messages. It's just not easy to get this data back once it's written.

I think people don't care much about good commit messages because they are unprofessional and sloppy. They just want to get the commit in, push the PR/MR, get it reviewed and merged, close that Jira ticket, and get credit for those sweet sweet story points (ugh). And on top of that, they generally don't care to document their changes because they personally don't see the value of doing so. Surely they'll remember the change if they ever revisit it (no of course not, but many people think they will), and they don't really give much thought to the possibility that others might need more context.

And besides, all the discussion about the bug or feature or whatever was happening in the bug tracker, so providing a link to that issue in the commit message is enough, right? (No, it's not; I hate it when people do that and think that's all they need to do.)

> The main issue is that most of the tooling (in Git or GitHub or whatever) generally only shows the first line.

Then maybe this is GitHub's fault; fix your web UI, then. I avoid GUI interfaces to my dev tools as much as possible, and I think the git command line is perfectly fine for this. It absolutely does not only show the first line, generally. 'git log', 'git show', etc. give you the full message by default. In general I would say you have to go out of your way (by providing more command line options) to hide the message when using the command line tools.

> the Git commit message is a unique vector for code documentation that is highly sub-optimal.

Sure, because it's not a vector for code documentation, it's a vector for change documentation. And there's no better place to put the description of a change than in the record of the change happening.

While I agree that many people write very poor commit messages, I don't think the tooling and discoverability is why.

Re: My favourite Git commit (2019)

#170

Post by JadeNB »

josephg wrote: post #113
Sohcahtoa82 wrote: post #84

Earlier quoted context omitted.

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

> 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 that a good thing, too? It's all too easy to treat a newbie as if they can't possibly have useful things to offer to the community; being forced to treat all comments equally, without being able to fall back on the crutch of reputation, arguably forces one to read and engage more deeply with the content, and offers the chance to surface the occasional genuinely valuable contribution from a newbie (or, for that matter, to avoid letting someone get away with an ill considered or overbroad statement just because they have such a big reputation that people are too afraid to stand up to them).

Post reply on HN