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

151–160 of 406 posts

Re: My favourite Git commit (2019)

#151

Post by winwhiz »

brabel wrote: post #92
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…

> 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 might be called something other than This PC if someone renamed it) or either press WINDOWS key or click Start or click the Windows icon (if you don't see them try mousing into a corner of your screen (typically bottom left) until they and the rest of the bar un-autohide) look for and click a gear symbol (should expand to say Settings if you hover), click System, on the left and the bottom you should see About. 2. Click the text Advanced system settings (on the right), look for a new window with a set of tabs, you want Advanced. Click the button Environment Variables. 3. In the top columnar box EITHER find a variable named Path, highlight and click button Edit, in a new window click button New, type '/opt/bin/git' in a text field that has appeared at the bottom list items, click OK OR click the button New, in a new window enter Path for Variable name and /opt/git/bin for Variable value, click OK (you shouldn't need to Browse Directory or Browse File). 4. Click OK button, click OK button, close Settings window.

Re: My favourite Git commit (2019)

#152

Post by fl0ki »

A complementary virtue is that the commit is tightly scoped to exactly one change. I still see most engineers commit whatever they had in their working directory as a sort of blanket Save Point, without any thought to how those changes can be captured as individual commits that can be commented and reviewed on their own merits.

This will typically also involve completely unnecessary changes, because when you're merging unrelated changes anyway, the unnecessary ones are swept up in the noise. At best they complicate rebases for other contributors, but too often they also cause outright regressions.

It goes without saying that the commit messages are a write-off at this point, because even if they felt motivated to take the time to comment it clearly, the change is so messy and nebulous that it becomes hard to comment on. If their code gets reviewed it's more likely the reviewer gives up and stamps it so they no longer have to look at it.

Most people still don't seem to know that `git add -p`, `git reset HEAD`, `git stash`, `git rebase --interactive`, etc. are even available. They never learn what git is capable of, so they act like version control is a bureaucratic obligation rather than the peerless superpower that it can be. The problems they cause don't end at their terminal though, because now they've made a mess of the repository for every other contributor as well.

Re: My favourite Git commit (2019)

#154

Post by ickyforce »

herrkanin wrote: post #74
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…

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 wants to learn the full history - the remarks during code review, perhaps all the WIP commits - they can read the PR/code review comments. I found it to be very rarely needed.

Re: My favourite Git commit (2019)

#156

Post by OJFord »

unregistereddev wrote: post #22
OJFord wrote: post #3

One thing I disagree with is: > I wouldn’t expect all commits ( especially ones of this size ) to have this level of detail. (emphasis added) - actually in my experience it's often the little ones, innocuous looking things that might really need a relatively longer explanation. Yesterday I wrote three paragraphs on why I added `--limit=999` to a `gh pr list` because it's confusing: there's already a `limit(` in the `…

I agree with you that the little innocuous things often need a longer explanation, but the linked commit message is way too long IMO. It either wastes the readers' time, or it causes the readers' eyes to gloss over at the wall of text. You don't need to document your entire journey in order to document your findings and explain why. > This was a non-ascii whitespace character that caused `ArgumentError: invalid byte…

Yes, it's not my preferred style either, but it's much better than 'fixes error' type thing, subject line only, that's so common.

I like the form:

    Fix ArgumentError 'invalid byte sequence'

    Non-ASCII whitespace characters cause [...]. This was apparent in [...] because [...].

    This commit fixes the issue by removing the offending character; so the file is now solely ASCII characters.
Or that sort of thing. Subject tells me why, body tells me what the problem was and how it was fixed. (Who, when, where are already in the commit metadata! The diff shows a very literal 'what' too, the what/how in the body should offer context and explanation as required.)

Re: My favourite Git commit (2019)

#157

Post by lisper »

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…

> The main issue is that most of the tooling ... generally only shows the first line.

> I don't know exactly what the answer is

Isn't it obvious? Write better tools. There is no reason you have to be stuck with the deficiencies of what someone else has built. That's the whole point of open-source software.

It's more than a little concerning that a "GitHub cofounder and author of several Git books" has to have this pointed out to them.

Re: My favourite Git commit (2019)

#158

Post by fl0ki »

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.

The only sets of arguments I use to git log regularly:

* `git log branch` because I want to cherrypick or checkout parts of another branch.

* `git log --stat` because what files changed can be a big clue for what I'm looking for.

* `git log -- dir1/ file1/` because I only care about commits to a certain part of the tree.

Other than that, `git log` already provides so much information to /search or even `grep` through that I can't think of any other flags I use regularly, and if you don't use them regularly you forget them.

The real GOAT that people are sleeping on is `git rebase --interactive` where you can go back and edit part of your branch to clean it up before rebasing or merging towards main. The cleaner the commits are, the more useful they become later for other tools like log, merge, rebase, cherry-pick, bisect, etc.

Re: My favourite Git commit (2019)

#160

Post by caskstrength »

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…

> 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 that are relevant to the code blocks you care about is not widely known and even if you find them, still only show the first line. Then you need to "git show" the identified commit SHA to get this long form message. There is just no good way to find this information, even if it's well written.

The good way to browse git blame a read commit messages is to use Magit. It is also great at letting you seamlessly rebase/split/merge long patch series.

Post reply on HN