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

181–190 of 406 posts

Re: My favourite Git commit (2019)

#181

Post by ChrisMarshallNY »

eschneider wrote: post #117
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…

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.

This.

I write documentation for me.

Very few folks ever use my published code, which is fine by me. I publish it, because treating my packages as atomic, ship-ready, high-Quality products, forces me to take great care, in each and every one.

Which means, when I use them in my other work, I don't have to worry about them.

My take on documentation is thus: https://littlegreenviper.com/miscellany/leaving-a-legacy/

Re: My favourite Git commit (2019)

#182

Post by arccy »

teaearlgraycold wrote: post #165
josephg wrote: post #113

Earlier quoted context omitted.

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?

pretty much yes, even here you see a lot of overconfidently mediocre takes

Re: My favourite Git commit (2019)

#183

Post by Anon1096 »

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.

Yep this message is way better. And honestly, looking at the diff in github it is pretty obvious to me what has changed (and why really, since the only reason for a changeset to have a diff look identical is that non-visible characters have been added or removed).

So all I'd require is a good main message for history-search purposes. A short story about how you went to Narnia and came back to find the root cause of a bug isn't really relevant imo but I'm also not against writing it if you just want to vent in a PR description/commit's extended message.

Re: My favourite Git commit (2019)

#184

Post by keybored »

sethammons wrote: post #122
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…

Any system where the proposed solution is "be better" without an outline of "and here is how" and some method of enforcement is doomed to fail. Checklists, build checks, linters, tests, SLOs, post incident responses, follow up tickets, etc all serve to unload "be a better software developer" into actual systems and processes that can continuously enable the better behavior. Simply stating "do a better job" wont work…

There were two hands in that comment (on the one hand/the other). One hand said that Git and other tools should be better. Only the other hand said to be better.

Re: My favourite Git commit (2019)

#186

Post by kelnos »

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.

> our pull requests are usually accompanied by a link to the bugzilla entry, which usually have a detailed explanation.

This practice annoys me quite a bit, actually. Well, if there is a bug tracker issue, of course, definitely link to it in the commit message. But that should provide extra, optional information; everything I reasonably need to understand the change should still be in the commit message. I don't want to have to chase down the information in an external system, a system which may not even be running anymore... and of course we all know that when systems get shut down, of course they get backed up and archived and made accessible properly every time... right.

Re: My favourite Git commit (2019)

#187

Post by arccy »

ickyforce wrote: post #154
herrkanin wrote: post #74

Earlier quoted context omitted.

If writing good commit messages isn't specifically defined as part of your job, why would you waste business hours writing commit messages that are beyond what is expected of you and frankly useless since nobody would ever read it anyway?

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

Re: My favourite Git commit (2019)

#188

Post by mb7733 »

schacon wrote: post #94
mb7733 wrote: post #70

Earlier quoted context omitted.

Well, `git` is still the primary way I interact with a git repository, and `git log` shows the entire commit message by default. So I don't run into this problem. If some "modern" git frontend is only capable of displaying the first line of a commit message, then this is a problem with that tool, not git itself. (I'm also not convinced this is a limitation of all modern tooling...)

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…

> I can't imagine that all of your interactions with your codebase are via `git log` with no other flags.

When did I say anything like that?

My point is just that the `git log` command, by default, shows the full commit message. The same goes for `git show`. So a user of the git CLI will regularly see complete commit messages, unless they purposefully request a different format. So, it is not some inherit problem in git that the complete commit message is hard to find. That's just a limitation of certain Git frontends.

Re: My favourite Git commit (2019)

#189

Post by kelnos »

mo_42 wrote: post #63

I have a different opinion about favourite Git commit messages. I think commits should be small steps that display the thought process of the author. Every individual commit should be self-explanatory. So the commit message should not describe (again) what the changes are but why it’s necessary. Sometimes the change is not self-explanatory and then I'd put a longer description below. Somehow I came up with this on my…

I just don't think this is feasible, and I think you're maybe over-estimating the diff-reading skills of others. I agree that changes should be as small and self-contained as possible, but I don't think it's reasonable to expect a later diff-reader to be able to understand what the change is just by looking at it.

Certainly a commit message should include the why, but it should include -- start with, really -- the what as well.

Re: My favourite Git commit (2019)

#190

Post by tehnub »

adrianmsmith wrote: post #24

I think the disadvantage with this style of documentation is you can't really alter the commit message after it's written. (I mean you could obviously with "rebase" but are you really going to alter something written one year ago, already merged to "main", and cause a bunch of pain with everyone's feature branch etc.?) Compare that with documentation stored in a .md file, or even a Wiki or even Confluence. My colleag…

I know this isn't a great solution, but GitHub does let you write comments on individual commits. You could add whatever addendums you want there.
Post reply on HN