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

401–406 of 406 posts

Re: My favourite Git commit (2019)

#401

Post by account42 »

nickm12 wrote: post #315

I'm not at all a fan of this commit message. The summary line is vague (what template? what error?) and then the body spends 250 words explaining all the steps it took to get to this fix. What is this, a recipe on the web? The commit message should explain the change being made, what impact it will have, and why it is being made. The audience is the developers reviewing the change or someone looking through the logs…

Agreed, this isn't a good commit message at all. Yes you should write detailed commit messages but this one is just verbose without adding much useful info. We don't need to know the exact command the original developer used to figure out the problem and we defenitley don't need to see his shell prompt including host name and all.

Re: My favourite Git commit (2019)

#402

Post by account42 »

WalterBright wrote: post #310
kelnos wrote: post #186

Earlier quoted context omitted.

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

I see your point. We are migrating to using github issues for that and related reasons.

That just means you are now relying on someone elses computer staying around, with URLs that you cannot control in the future if you need to. It doesn't actually solve the problem.

It also means that the explanations are not seachable locally.

Re: My favourite Git commit (2019)

#403

Post by account42 »

boolemancer wrote: post #392
WalterBright wrote: post #279

Earlier quoted context omitted.

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

> If it actually looks different, then it becomes a different code point. Which language gets the original code point and which one needs to change? And what happens to all of the existing text written with the original code point?

Obviously we are stuck with Unicode as-is now, warts and all. But that doesn't mean that the original design was the right one.

Re: My favourite Git commit (2019)

#404

Post by account42 »

yura wrote: post #194
fusslo wrote: post #25

great commits are great. This is fantastic As an aside, I'm tired of documenting: - in code - in commits - in jira - in confluence - in daily standups - in release notes

- in code: code-level context - in commits: changeset-level context - in jira: if you need to provide changeset-level context, point them to the MR/commit log - in confluence: high-level documentation - in daily standups: status update; if you need to provide changeset-level context, point them to the MR/commit log - in release notes: generate automatically from commit log IMO duplication in documentation should be t…

Agreed except for

> - in release notes: generate automatically from commit log

Release notes are for a completely different audience and should be custom-tailored to that audience. They also shouldn't include changes that were reverted or made redundant by later changes in the same release.

Sure, commits-as-change-log is better than no change log but still very very far from optimal.

Re: My favourite Git commit (2019)

#405

Post by Capricorn2481 »

michaelcampbell wrote: post #390
atq2119 wrote: post #385

Earlier quoted context omitted.

Interesting that you perceive a dichotomy there, can you elaborate where you see the conflict? As a reviewer, I see myself as a (extremely near, time T+epsilon) future developer who is trying to see what the hell is happening.

There's a dichotomy between a history of actual code changes, oopsies and redos included, and "a carefully crafted story of the intent of this change". One is an ugly reality, the other is a pretty story of intention. The process vs. the final result. Both are useful, but in different contexts. The latter is good for a PR, but when optimized for that often loses a lot of other context, and is meant to be a throwaway…

> The former can delve a bit into what experiments were tried and abandoned and can give a lot more meaning to the final result.

I haven't found this to be true at all. Commits don't tell me anything other than when the coder left their desk for the moment. When there's a policy that allows people to have a "rough, ugly history", where a coder chooses to commit is completely arbitrary. I would argue that the clean, crafted story is the only helpful one.

You can argue that a coder shouldn't be committing unless they are at a natural milestone that can be annotated, but I would consider that the "crafted" story.

Re: My favourite Git commit (2019)

#406

Post by neilkk »

thfuran wrote: post #280
neilkk wrote: post #253

Earlier quoted context omitted.

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.

All communication is communication with people in the future.
Post reply on HN