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

191–200 of 406 posts

Re: My favourite Git commit (2019)

#191

Post by mb7733 »

bee_rider wrote: post #147
schacon wrote: post #94

Earlier quoted context omitted.

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…

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.

I don't know how my comment was understood to mean that I am unfamiliar with git. My point was that those of us that use the git CLI have no issues seeing the rest of a commit message besides the first line, and in fact this is the default.

Re: My favourite Git commit (2019)

#192

Post by jakub_g »

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…

In my experience it all depends on what kind of codebase it is (product? library/framework? private company? opensource?), commit velocity, release cadence & how the codebase is used in general.

In low-velocity opensource libraries, good and clean commit messages can be really helpful when debugging arcane issues. I used to be maintainer of a frontend framework & widget library and we tried to have good commit messages as we'd often go back when over old commits when fixing bugs.

I agree that using git from command line for blame is not easy, this is something I always do from GitHub UI instead.

When GitHub is the repo's choice for PRs, and the codebase is product codebase with high velocity, having a pristine git history and clean commits and commit messages is not practical; however, the expectation should be to at least have good PR descriptions. When blaming commits in GH UI, it's easy to go to the PR which introduced the commit (it's linked below commit title); and PR descriptions can be enforced via templates in .github folder.

PR descriptions have an advantage that they can use images, videos etc. to better explain what they change. This is especially useful for frontend codebases.

I work on a big frontend monorepo. We have tools in place to do visual bisect between pull requests (each PR gets its own preview env). We very much do read PR descriptions when doing bisect to confirm which of the recently merged dozens of PRs introduced a regression in production N hours ago.

But in general I agree that commit messages are not good place to storage general knowledge (they're good for "what and why is changing here"). For documenting gotchas etc. I prefer to have code comments in relevant places of code; or README.md in subfolders. (Sadly, I notice most programmers just don't document anything anywhere at all).

Re: My favourite Git commit (2019)

#193

Post by kaashif »

erik_seaberg wrote: post #140
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?

Writing good commit messages is part of your job in the sense that no reviewer should be approving anything without them, knowing that you may or may not be available if it breaks next year at 3 AM.

I put that kind of thing in the pull request, since that's where the review happens. Every commit links back to a pull request, and people actually do refer back to it. Writing good documentation there is part of the job.

No-one's going to ALSO write commit messages that no-one will see.

Re: My favourite Git commit (2019)

#194

Post by yura »

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 treated the same as in code – it should be avoided as much as possible.

Re: My favourite Git commit (2019)

#195

Post by kelnos »

GuB-42 wrote: post #129
marcosdumay wrote: post #37

Earlier quoted context omitted.

The code and commit documentation are about different things. One is about what this thing is, the other is about what is changing. But then, jira is about what is changing, confluence is about what is changing, standups are about what is changing (oh, but this is doing them wrong), and release notes are about what is changing. So your complaint is completely reasonable, just the first item shouldn't be there.

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 example, that comment is superfluous; the constant should just be called MAX_SUPPORTED_SIZE, or something similar, that describes it better and makes the comment redundant and unnecessary.

Otherwise I agree; there's so much redundancy in our work, it's silly...

Re: My favourite Git commit (2019)

#196

Post by teaearlgraycold »

arccy wrote: post #182
teaearlgraycold wrote: post #165

Earlier quoted context omitted.

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

It’s important to know how to stick to your course in the face of bad advice.

Re: My favourite Git commit (2019)

#197

Post by kelnos »

AeroNotix wrote: post #66

Essentially zero people read complex commit messages. Do with this information what you will. 9/10 the code already is documentation enough for what the code currently does, if you need to go back through history then look at the commits. The messages are generally noise. I've literally never cared _why_ someone made a change, I can see the change, I can see the effect of the old and new code. Rarely, if ever, has th…

Even if it's true that essentially zero people read complex commit messages, that one person who needs to read it, 2 years later, will really appreciate its existence.

To me a commit message isn't there so someone can sit around and read commit messages to tell themselves a story. It's there in the -- hopefully unlikely -- possibility that there's a problem with the change, and someone needs to come back to it later, with no context, and understand why it was made so they can figure out what needs to be done.

I've absolutely used commit messages when debugging, and I don't think there's anything wrong with that.

Re: My favourite Git commit (2019)

#198

Post by b33j0r »

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…

Author of nit, here. I tried to move the landscape towards semantic reasoning. It’s on github but kind of abandonware. Life and incompetency happened ;)

No shilling. I commented here because I still think my framework was decently thought out, and mostly that calling someone a nit or a git is exactly what linus was thinking. Make it easy enough for anyone to use.

Nit is something people could take as a thought experiment.

Re: My favourite Git commit (2019)

#199

Post by kelnos »

AeroNotix wrote: post #96
advisedwang wrote: post #80

Earlier quoted context omitted.

> Essentially zero people read complex commit messages I don't think that's true. I worked in support doing break/fix and outage response work at a large organization. That means constantly dipping into codebases I'm utterly unfamiliar with. Often there is complexity, un-obvious elements, previous incorrect attempts at a bugfix and so on, where understanding what the author intended can save literal hours of examinat…

> [..] where understanding what the author intended can save literal hours of examination, experimentation etc. The problem with that it that you are relying on an inherently unreliable source of information - a human to enter details which may or may not lead you to the correct path. The code doesn't "lie". Just read it and the current issue and work from there.

> The code doesn't "lie". Just read it

No thanks. Some diffs aren't obvious. I'm not a mind reader. Having extra context is useful.

Post reply on HN