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

281–290 of 406 posts

Re: My favourite Git commit (2019)

#281

Post by cerved »

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…

Worse, PR tools like Azure DevOps (and GitHub?) don't do a good job of displaying the information.

Just a big diff.

I often get asked about the reason for a change in a review comment, even when there's a thorough description in the backing commit.

It's sad. I would prefer PRs over email like Git does

Re: My favourite Git commit (2019)

#282

Post by spacemankiller »

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…

> Edit to add: I didn't address your argument, that commit messages are too hard to find. First, I don't find this to be true. I rarely have trouble following the history of a line of code, a function, or a file.

I don’t think this is proper way of reasoning. What is hard and easy is subjective. And you discuss it as it would be objective. Word against word. It would be wise to have some poll and see results.

If one geek is writing and reading commit messages doesn’t mean it’s easily accessible by everyone. It’s hard to make something as a widespread standard if tooling doesn’t make it super easy to access. Allow people to leave kudos and emoji to other people commits messages and people will start making them better :D And later show heroic people with git —-stats

Re: My favourite Git commit (2019)

#283

Post by agubelu »

thefourthchime wrote: post #237
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…

I agree. My view is that you shouldn't write comments because if you have to, then your code isn't clear or organized well enough. If you do need a comment, perhaps to document a "Chesterton's Fence", you should put a big nice comment block to explain why and what's going on. The reality is people don't like to read, if they do it'll be an overview of how the code is organized, they don't want to read git commits or…

I think the "code should be self-documenting" view is a bit simplistic.

Good comments shouldn't explain what the code is doing, I agree that should be evident from the code itself if it's clear enough. However, why the code is doing what it's doing, or why it's being done in a certain way and not in a different way, is meta-information that is very hard to express in the code itself, and that's where comments are most useful.

Re: My favourite Git commit (2019)

#284

Post by kubanczyk »

fl0ki wrote: post #152

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

> git add -p

That command is a UX monstrosity and don't ever prompt any junior to use it. Use magit, use jj, use your IDE, just not that.

I agree with your overall sentiment however. I try to measure up commits in anticipation of future revert(s). A commit is a minimal change that can still (1) pass UT (2) become a sensible revert one day. That's my measuring stick.

Re: My favourite Git commit (2019)

#286

Post by ninkendo »

Anon1096 wrote: post #183
rpsw wrote: post #27

Overall agree with the sentiment, but I would add a more specific Bottom Line Up Front (BLUF) such as: "Fix test issues caused by non-breaking space character \xa0". Tells me exactly what the problem was straight away, but I'm still free to choose to read more if I want to know more.

Yep this message is way better. And honestly, looking at the diff in github it is pretty obvious to me what has changed (and why really, since the only reason for a changeset to have a diff look identical is that non-visible characters have been added or removed). So all I'd require is a good main message for history-search purposes. A short story about how you went to Narnia and came back to find the root cause of a…

Stories about how you went to narnia and back may be useful to a future contributor who finds themselves in narnia. This is very likely not the last time that an invalid byte sequence will show up in one of the source files in this tree, and if it happens again, it may be good to see the symptoms in the git log.

Re: My favourite Git commit (2019)

#287

Post by djha-skin »

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…

This sounds like an excellent sales pitch to use email based good workflows such as those advocated for by Drew DeVault[1].

1: https://git-send-email.io/

Re: My favourite Git commit (2019)

#288

Post by ninkendo »

tuetuopay wrote: post #45
tux3 wrote: post #18

Earlier quoted context omitted.

In some orgs, people never run a bisect. Not once a year. They go as far as squashing out swaths of history into big un-reviewable blobs. Once code has been merged, they never look inside a past commit again. In spite of isolated (desperate) demands for rigor, it works fine.

I despise squashs. It encourages people to tread git commit as a glorified ^S of their work. You want to know why a change was made, or who so that they can explain it. You land on a blob of a diff, with no meaningful commit message (any commit message was squashed to /dev/null to be replaced with the MR title and description). And then off you go to the corresponding github/gitlab/whatever MR only to find a wall of…

> I despise squashs. It encourages people to tread git commit as a glorified ^S of their work.

I can’t imagine working with git any other way. Do you hold off committing because you haven’t collected your thoughts enough to craft a good message? What if your editor crashes and you lose your undo history? How do you get back to the last state where the code compiled? If some plan of attack doesn’t work, you just… reset hard and lose it forever?

I can’t count the number of times I’ve done something like the following:

- Try approach A

- Approach A sucks, commit what I’ve done so far, try approach B

- B sucks too, commit again and switch back to A (oh hey, there it is in my reflog!)

- Turns out I need a combination of A and B. Oh hey, a simple git diff shows me the deltas. Awesome!

- Repeat

- Once I’m ready to make the PR, I squash it all, craft a thoughtful, meaningful commit message, look at the commit as if I’m a reviewer, verify it all makes sense in context as a single commit.

(oh and by the end, the commit may be a SINGLE CHARACTER! Precisely what the author of this article is talking about! Is it your contention that every dead-end the author hit should have a permanent place in the repo’s commit history, forever?)

In your world, do you just… not use git at all here? Do you never try approach until you’re sure it’s the right one? You only commit when you have something you want someone else to see? That’s nuts to me. You’re absolutely missing out on some of the best workflow git has to offer.

Re: My favourite Git commit (2019)

#289

Post by o11c »

atahanacar wrote: post #7
aeurielesn wrote: post #2

I had a terrible time when someone used "smart quotes" (beautified Office quotation marks) in a configuration file. I believe this was only possible because they copied it from Outlook.

>smart quotes I never understood why a "stylistic" choice requires separate characters. If we don't need a serif and non-serif version of every character and instead leave it to the software, why can't we do the same with the "smart" quotes?

Double quotes can be unambiguously autodetected by checking word boundaries, but separate single quotes are needed since apostrophe is the same character as a close quote, but can appear at the start of a word. Note that most smart-quote-generating software does fail badly at this.

Some common ambiguous pairs:

’bout - abbreviation for "about"

‘bout - starting a quote about a round of a fight

’cause - abbreviation for "because"

‘cause - starting a quote about a reason or ideal

’em - abbreviation for "them"

‘em - starting a quote about typographical units

’n’ - abbreviation for "and"

‘n’ - speaking of the letter itself

Re: My favourite Git commit (2019)

#290

Post by mschuster91 »

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…

> Do you really try to stick with the git CLI and memorize hundreds of commands and flags?? Why?!

Because IntelliJ is... less capable than it should be. Personally, I find `git add/commit -p`, `git diff` far easier to use than IntelliJ, and because Python is a fucking mess I had to install the codecommit git helper into a Python venv... but you can't tell IntelliJ to use that venv's $PATH for `git pull`/`git push`.

Oh, and you can't really macro complex stuff in IntelliJ, whereas I can do a single-command release and push-tag of a project with about 30 Git submodules in a (convoluted) Bash one-liner.

Post reply on HN