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

311–320 of 406 posts

Re: My favourite Git commit (2019)

#311

Post by nox101 »

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…

I'm mixed on this. My project has a bug tracker. A commit is required to have a bug id. The bug tracker has entire discussions of what lead to the commit so it's not clear to me that a detailed commit message is a plus when the real detailed info is in the tracker. Yes it's indirect but there's no way I'm going to summarize the entire issue discussion.

Maybe this is a job for machine learning. Read the code, read the commits, read the bug tracker, add a git super-blame that asks the LLM to summarize why every line is the way it is and what it's doing

Re: My favourite Git commit (2019)

#312

Post by ghqst »

nox101 wrote: post #311
js2 wrote: post #107

Earlier quoted context omitted.

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…

I'm mixed on this. My project has a bug tracker. A commit is required to have a bug id. The bug tracker has entire discussions of what lead to the commit so it's not clear to me that a detailed commit message is a plus when the real detailed info is in the tracker. Yes it's indirect but there's no way I'm going to summarize the entire issue discussion. Maybe this is a job for machine learning. Read the code, read the…

This is why at work the only required rule for commit messages is that they include the story number, so we can very easily find at least the general reason for a change from git blame.

Re: My favourite Git commit (2019)

#313

Post by atq2119 »

neilkk wrote: post #208
js2 wrote: post #107

Earlier quoted context omitted.

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

Then don't write commit messages for the future, write them for reviewers.

Seriously, as somebody who reviews a lot of code, well-written commit messages are a godsend.

It's an awful shame that GitHub doesn't allow commenting on commit messages. It's as if GitHub is being run by people who just don't know how Git is meant to be used.

Re: My favourite Git commit (2019)

#314

Post by atq2119 »

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…

I feel like you're complaining about a problem which you helped create.

So, with all due respect, do your part to fix it. For example, by allowing review comments on commit messages in GitHub. Gerrit gets this right, FWIW.

Re: My favourite Git commit (2019)

#315

Post by nickm12 »

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 to determine why this line changed.

Re: My favourite Git commit (2019)

#316

Post by corethree »

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…

His credentials indicate that it may be possible that his arguments are based on data while your credentials and evidence indicate personal, anecdotal experience. Therefore I would trust his reasoning more. Additionally, I personally identify with it.

I mean a git developer finds git easy to use? That's biased data.

I love how both of you dropped your street cred before launching into your reasoning. It just shows how much more credentials convinces people rather then the argument itself. Normally that stuff logically doesn't matter and people are just doing it to grab some "authoritah" but in this case your backgrounds actually contributed to the arguments.

Re: My favourite Git commit (2019)

#317

Post by u801e »

nox101 wrote: post #311
js2 wrote: post #107

Earlier quoted context omitted.

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…

I'm mixed on this. My project has a bug tracker. A commit is required to have a bug id. The bug tracker has entire discussions of what lead to the commit so it's not clear to me that a detailed commit message is a plus when the real detailed info is in the tracker. Yes it's indirect but there's no way I'm going to summarize the entire issue discussion. Maybe this is a job for machine learning. Read the code, read the…

> A commit is required to have a bug id. The bug tracker has entire discussions of what lead to the commit

Companies do change bug trackers and ticketing systems and those links may no longer work years down the line.

> The bug tracker has entire discussions of what lead to the commit so it's not clear to me that a detailed commit message is a plus when the real detailed info is in the tracker. Yes it's indirect but there's no way I'm going to summarize the entire issue discussion.

But summarizing it can be one of the most valuable things you can do for a maintainer who has to make changes years after you've moved on. For one thing, the problem and discussion is fresh in your mind and you understand the context. In a few minutes, you could summarize the problem, the approach taken to fix it and alternatives that were considered but not used because the chosen solution clearly didn't have an issue/was more efficient, etc.

Even if you didn't want to do that, you could just copy and paste the entire discussion text at the end of the commit message so that even if the bug tracker is no longer in use in the future, the discussion itself was preserved in the commit history and accessible via git log or blame.

Re: My favourite Git commit (2019)

#318

Post by u801e »

atq2119 wrote: post #313
neilkk wrote: post #208

Earlier quoted context omitted.

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

Then don't write commit messages for the future, write them for reviewers. Seriously, as somebody who reviews a lot of code, well-written commit messages are a godsend. It's an awful shame that GitHub doesn't allow commenting on commit messages. It's as if GitHub is being run by people who just don't know how Git is meant to be used.

> It's an awful shame that GitHub doesn't allow commenting on commit messages.

You actually can comment on a commit itself. I'm in the habit on middle-clicking on the sha1 link of commits in a PR and looking at the commit itself. You can comment on lines in the commit, and there's a text area at the bottom where you can comment on the entire commit itself. I'll then follow up with making a comment on the PR linking the commit (pasting the sha1 link) and saying I made a few comments here.

> It's as if GitHub is being run by people who just don't know how Git is meant to be used.

Github wasn't really designed with code review in mind. A lot of the features they added over the years for review appear to be hacked on rather than fixing fundamental design issues (like being able to comment on commit messages without having to jump through a bunch of hoops).

Review systems like gerrit, phabricator, review board, or even email, do a much better job at exposing individual commits and their associated metadata like the commit message.

Re: My favourite Git commit (2019)

#319

Post by dullcrisp »

WalterBright wrote: post #308
dullcrisp wrote: post #296

Earlier quoted context omitted.

How about an l and an I? Or a closed "a" and one with the little handle? A zero with a stroke, a zero without a stroke, and an O? I can see where you're coming from, but deduplicating every glyph from every culture based on which do or don't generally look the same when printed sounds like a tall order. And if all you want to record is the shape, you can use a PNG with OCR and bypass Unicode entirely.

> How about an l and an I? Or a closed "a" and one with the little handle? A zero with a stroke, a zero without a stroke, and an O? Those are font differences, not character differences. (Unicode has also failed by adding in some fonts. The nuttiness never ends.)

But just as the “a” in alphabet and the «а» in азбука are only distinguishable by context, so too the “O” in SOS and the 0 in 90210 are often only distinguishable by context. I don’t see how you propose to determine which glyphs should be the same and which should be different in your system.

Re: My favourite Git commit (2019)

#320

Post by rablackburn »

gregmac wrote: post #258
winwhiz wrote: post #151

Earlier quoted context omitted.

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…

Your fictional example is not a good comparison -- I just can't imagine the scenario where you need to explain to someone who doesn't know how to modify their path why they need to add something to it. For someone actually using git (and the CLI, at that) I'd expect to be able to say "oh, make sure git is in your path" and for them to understand how to check and set that, or at least be able to Google it and follow t…

> I just can't imagine the scenario where you need to explain to someone who doesn't know how to modify their path why they need to add something to it.

Sounds like someone hasn’t had to train fresh graduate engineers for awhile ;)

Post reply on HN