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

201–210 of 406 posts

Re: My favourite Git commit (2019)

#201

Post by kaashif »

ajuc wrote: post #43
spenczar5 wrote: post #5

I have felt that pride in writing a great commit message, but I am less sure of the value to others. I don’t think most people search commit messages when they encounter an unusual error message, or when adding a new feature, or really almost ever. It’s a bit sad, but I have a growing suspicion that beautiful commit messages are a bit of vanity by the programmer. The person primarily impressed is often the author; ot…

If you change a line of code without doing git-blame on it first you're doing it wrong. I've been bitten by this many times - I change obvious bug, I'm about to commit the changes, I see the previous commit which introduced the "bug" on purpose and the attached JIRA task has perfectly good explanation for why my obvious change would have reintroduced some bug from 2 years ago :)

> If you change a line of code without doing git-blame on it first you're doing it wrong.

Working on a project where this is necessary sounds like a hellish experience.

The place for comments explaining why the code is needed is right next to the code! On an adjacent line!

Re: My favourite Git commit (2019)

#202

Post by nonethewiser »

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…

The "just do your damn job" retort presupposes that their job is to read the entire body of every git commit. That's the question - you can't just presuppose it.

Re: My favourite Git commit (2019)

#204

Post by tetha »

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.

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

Very much this.

If I'm modifying some rather obvious and ovreall simple thing like an obvious config of a grafana, adding a customer to a config and such things... it's hard to really bother with a long commit message. Also, with modern tools like VSCode with the Gremlin plugin, I don't think I'd have spent many words on removing a weird whitespace from a code base, to be honest.

On the other hand, if I've spent 4 hours thinking and 2 of those hours discussing the change with another DBA changing a 2 into an 8 in the config of an SLA-critical postgres cluster... spending 10 minutes on a commit message in the config management is - with regard to time - a footnote, irrelevant and inconsequential.

But it can be worth more than gold down the road if you ask "Why 8? Why not 6!"

Re: My favourite Git commit (2019)

#205

Post by keybored »

winwhiz wrote: post #151
brabel wrote: post #92

Earlier quoted context omitted.

> Even if you're _very good_ at Git, finding the correct invocation of "git blame" (is it "-w -C -C -C"? Or just _two_ dash C's?) to even find the right messages I am terrible at git on the terminal, but with IntelliJ or emacs and magit, I can trivially find every commit ever to change a file, and easily navigate the commits to see every full commit message. It's not hard when you use a proper tool, and I have a feel…

Really simple answer: Repeatability. I am not saying it is the only one right blessed answer, but if you really want to know why people haven't moved to pure GUI interfaces, imagine describing to someone how to add a new directory to their path. fleet $HOME/.config/fish.config # ADD this line somewhere set -x PATH /opt/git/bin $PATH Or: 1. Either hit WINDOWS-E and right click on This PC and select properties (it migh…

If the tool calls git(1) then it can show you the script that your actions produced. Magit has something like this but I’ve never used it for that (since I also use git(1)) so I don’t know if it captures the whole context/commands.

I used a GUI frontend to R in a statistics course. Never needed to write R myself.

Re: My favourite Git commit (2019)

#206

Post by theamk »

Cthulhu_ wrote: post #146
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…

This is the problem with any kind of documentation; while you can write the highest quality, meticulous, most obvious and clearest prose, it's moot if nobody reads it. And nobody reads it because there's so much of it and there's no clear starting point. People just want the summary of what they're looking for. I started to learn Java almost 20 years ago, we had a text book and everything. After the first two chapter…

Nah, we have documentation with a clear starting point - there is index page with most common topics, "new user" page with links to what new user should read, and some error messages actually contain wiki links to pages with instructions.

And yet we still have people who don't read documentation.

Re: My favourite Git commit (2019)

#207

Post by lazyasciiart »

schacon wrote: post #71
codemac wrote: post #65

Earlier quoted context omitted.

It's great for historical research though. It's one of the few pieces of documentation that will live with the code forever. github and other forms of centralization are not open data formats that folks trivially backup/convert/carry forward. They usually leave the data behind if they move the project somewhere else. So no, I don't think it helps the current community much either. But it helps the debugger years late…

Is it great for historical research? I feel like the format and tooling around it is uniquely _not great_ for historical research. I think it's optimized for discussions before integration, which is largely what PR descriptions and comments are largely used for now. I feel like given great commit messages, determining a story and useful history around any block of code given the Git tooling is incredibly difficult ev…

P4V (Perforce Visual Client) is amazing for visual historical research. I haven't seen a git tool like it, but I'd love one. https://www.perforce.com/video-tutorials/vcs/using-time-laps...

Re: My favourite Git commit (2019)

#208

Post by neilkk »

js2 wrote: post #107
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…

As someone who has contributed to Git since before GitHub existed and who maintains legacy code, I simply cannot disagree more. I use `git blame`, `git log`, and `git show` in the terminal all the time. It's trivial to follow the history of a file. It takes me seconds to use `git log -G` to find when something was added or removed. Nothing pains me more than to track down the commit and then find a commit message tha…

The thing is that writing a good commit message for future people doing `git blame` is only worth it if it's a line of code which someone in the future will look at and need to know why it was changed from its previous form to the current form.

If you simply want to comment the current state of the code, you should add a comment in the code.

No one will ever need to know in the future why that particular space character is an ascii space, so the whole commit message is just a blog entry in the wrong place.

It would have made sense to just put a comment at the top of the file saying "make sure encoding is whatever".

Re: My favourite Git commit (2019)

#209

Post by Dylan16807 »

winwhiz wrote: post #151
brabel wrote: post #92

Earlier quoted context omitted.

> Even if you're _very good_ at Git, finding the correct invocation of "git blame" (is it "-w -C -C -C"? Or just _two_ dash C's?) to even find the right messages I am terrible at git on the terminal, but with IntelliJ or emacs and magit, I can trivially find every commit ever to change a file, and easily navigate the commits to see every full commit message. It's not hard when you use a proper tool, and I have a feel…

Really simple answer: Repeatability. I am not saying it is the only one right blessed answer, but if you really want to know why people haven't moved to pure GUI interfaces, imagine describing to someone how to add a new directory to their path. fleet $HOME/.config/fish.config # ADD this line somewhere set -x PATH /opt/git/bin $PATH Or: 1. Either hit WINDOWS-E and right click on This PC and select properties (it migh…

Have you ever heard of "abstraction"? People that actually use windows can handle opening the start menu as a single part of a step. There's no conscious checklist for how the UI can be customized.

If you're going to make that into a complicated mess, then you absolutely do not get to assume the user understands "add this line somewhere" or has "fleet" installed and set up the way you expect.

Re: My favourite Git commit (2019)

#210

Post by wnoise »

kaashif wrote: post #193
erik_seaberg wrote: post #140

Earlier quoted context omitted.

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.

The git history will last longer than the platform hosting the PR.
Post reply on HN