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

171–180 of 406 posts

Re: My favourite Git commit (2019)

#171

Post by EdwardDiego »

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…

Don't even need the set -x, can just use fish_add_path for convenience.

Re: My favourite Git commit (2019)

#172

Post by jeremyw »

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 take Scott's point with a difference perspective.

Though commit messages are ephemeral and hard to utilize in the future, they're the stream of consciousness of the project.

They convey very important shifts in direction, discoveries in the making, code smells, limits of current architecture, and markers of tech debt. We don't know what this beast will be. And we figure it out commit by commit. Document it.

Re: My favourite Git commit (2019)

#173

Post by lanstin »

codemac wrote: post #65
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…

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…

Till the team you are handing off the code to just copies the files and commits into a fresh new repo without any of the history. I had this happen once to a server I wrote, and then like 2 years later the new team comes and asks me if I knew of the server, and I'm like "I wrote it" and then they are all confused.

Re: My favourite Git commit (2019)

#174

Post by [deleted] »

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…

[deleted]

Re: My favourite Git commit (2019)

#175

Post by marwis »

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…

On Windows it's actually just:

1. Press Win key 2. Type env 3. Choose system or account

Re: My favourite Git commit (2019)

#176

Post by nijave »

tcoff91 wrote: post #68
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…

Many editors have great git blame integration that makes these messages quite accessible. It's really easy in emacs with magit to view commit messages from git blame view. I believe vim, vscode, and jetbrains IDEs all make this simple.

Yeah, a lot of these also have Github and ticket tracker (Jira, etc) integration so they'll also pull in context from those, too

Most of the stuff I work on uses merge commits on Github so you can just click the PR # in the merge commit message and arrive at the PR, browse through commit messages, discussion, etc

Re: My favourite Git commit (2019)

#177

Post by tehnub »

I try to write useful commit messages. Sometimes they're as expansive as this example, but not always. On GitHub, at least the way my team uses it, the PR is the more visible unit of code change. If you have a single-commit PR, GitHub will automatically make your commit message the PR description, which is nice. It does not do that if you have more than one commit, in which case I write a general overview of the changes and write "See individual commit messages for more detail" in bold.

Re: My favourite Git commit (2019)

#178

Post by kelnos »

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 both agree and disagree. I think you're right that most commit messages won't end up being seen. But when you do need to see one, having a good commit message can be critical to understanding a change, especially if the person who made the change is long gone by the time you need to look at it. Or, hell, if that person was you, but it was far enough in the past that you don't recall the details.

Re: My favourite Git commit (2019)

#179

Post by bastardoperator »

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…

Why would I waste time reading this paragraphs long commit message when I can look at a diff and a 40 character headline and completely understand the issue? You think it's lazy, I think this is wasteful. Personally I don't need an epic story about making a one character change because your editor isn't configured to catch gremlins... it's just not that interesting.

Re: My favourite Git commit (2019)

#180

Post by kelnos »

adrianmsmith wrote: post #24

I think the disadvantage with this style of documentation is you can't really alter the commit message after it's written. (I mean you could obviously with "rebase" but are you really going to alter something written one year ago, already merged to "main", and cause a bunch of pain with everyone's feature branch etc.?) Compare that with documentation stored in a .md file, or even a Wiki or even Confluence. My colleag…

A commit message isn't documentation that should be updated as things evolve. It's a historical record of a single change. Sure, if you later realize you forgot to put an important detail there, that's a shame. But overall I think it's actually important that they can never change.
Post reply on HN