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

331–340 of 406 posts

Re: My favourite Git commit (2019)

#331

Post by jeremyw »

yencabulator wrote: post #293
jeremyw wrote: post #172

Earlier quoted context omitted.

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.

Commit messages are the very opposite of ephemeral; they are the longest-lasting history a project is likely to have!

Yes, I misworded. The usefulness of commit messages, Scott's point.

Re: My favourite Git commit (2019)

#332

Post by lambda »

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 amazing, your experience with Git is so different than my own.

I routinely open a file in my editor, hit "Ctrl-c v B" for Git Blame mode, go to the line I'm interested in, and hit "Enter". Bam, there's the full commit message. From there I can can continue to trace backwards, blaming lines and reading full commit messages.

But, you know, not everyone uses Emacs and Magit, fair. How about just using "git gui blame file"? Click on a blame line, see the full commit message. This is a tool included with Git (available in a separate package in some installations).

OK, rather use an IDE? Install GitLens in VSCode. Easily accessible blame in your editor, where you can hover or click in various places to see full commit messages.

I mean, I agree in part; there are some tools which make good commit messages hard to write or find. The tiny little commit message edit box in VScode is not ideal. Lots of people use a workflow of "commit lots of crappy commits with one liner commit messages, let GitHub/GitLab squash them on merge."

But as an expert Git user who has managed to convince some teams to have a good commit message culture, if you do get people used to writing good commit messages, they can be very easy to find and read later on, there are tons of tools that make them easy to browse.

Re: My favourite Git commit (2019)

#333

Post by kimixa »

phaedrus wrote: post #328
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…

So then I am not wrong that I do all my git commit messages via the "-m" commandline option with a short phrase like "frob the baz"? (Initially I started using -m to avoid getting trapped in Vim. But even after I gained the option to use e.g. Notepad++ as the editor, I never saw the point in using anything more than "-m 'message'".)

Git respects the EDITOR environment variable and has done for decades (so likely before many here really used it) - you should probably be setting that (or equivalent on your platform) to the editor you want anyway.

Weird workaround just to avoid basic configuration seems like more work in the long run.

Re: My favourite Git commit (2019)

#334

Post by cerved »

yencabulator wrote: post #292
cerved wrote: post #277

Earlier quoted context omitted.

Right. The massive commit with minimal description and a PR number which I can look up in Azure DevOps to find a review with no description, no discussion and a mention of a number I can go and look up in Jira, where some Scrum master wrote half a sentence of what needs to be done and asking to "reach out to Jeff" for explanation. So much more valuable and great user experience

Just wait till next year when your employer migrates away from Azure DevOps and that PR number will be a dangling link forever lost.

Or you just move the repository to a different protect

Re: My favourite Git commit (2019)

#335

Post by adityaathalye »

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 don't know exactly what the answer is, but the sad truth of Git

> is that writing amazing documentation via commit message,

> for most communities, is almost entirely a waste of time.

> It's just too difficult to find them.

I completely agree that well-written git log messages are goldmines of information.

I wish makers of popular git forges had made it easier to create and consume this information.

Almost all my wiki pages start with piping git log messages into a text file.

Git logs are the entry point to good project documentation.

(edit: fix formatting)

Re: My favourite Git commit (2019)

#336

Post by Groxx »

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 feel like this explains a lot about why GitHub is so consistently hostile towards showing or writing decent commit messages.

Which has helped push people away from writing useful ones, on an unprecedented scale, which makes it a self-fulfilling prophecy.

Great.

Just great.

Re: My favourite Git commit (2019)

#337

Post by kimixa »

lambda wrote: post #332
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 amazing, your experience with Git is so different than my own. I routinely open a file in my editor, hit "Ctrl-c v B" for Git Blame mode, go to the line I'm interested in, and hit "Enter". Bam, there's the full commit message. From there I can can continue to trace backwards, blaming lines and reading full commit messages. But, you know, not everyone uses Emacs and Magit, fair. How about just using "git gui blam…

I regularly use the git command line, and "git show (pasted SHA)" in my second terminal doesn't really feel like the road block to understanding the grandparent seems to make it out to be. It takes me many orders of magnitude more time understanding what is output rather than searching for it, and like you mentioned there are any number of UIs (third party, editor integration, or even shipped with git like gitk) that wire everything up into a nice UI.

And I also disagree with the GP's complaint that "Most people only read the shortlog" being any kind of disadvantage. The commit message isn't for everyone, it's for the one time someone needs to figure out exactly what it did and why that commit was made, and why a change in X causes a behavior change in Y, and can save hours of work. It's like code comments, 99 times out of 100 you don't need them as you're just interacting with a documented API, but that 1 other time they are a godsend.

Re: My favourite Git commit (2019)

#338

Post by gloosx »

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 use fugitive.vim, and blaming is very convenient there as well as every other git workflow. I can press a shortcut to see when every line in the current file was changed, and who changed it along with the commit hash. If I need more – I can expand every hash to see the full context, including full commit text and diff. Maybe cli git is not too easy to use since how complex it is, but there exists a git wrapper so awesome it should be illegal

Re: My favourite Git commit (2019)

#340

Post by zilti »

wnoise wrote: post #231
zilti wrote: post #46

Earlier quoted context omitted.

Fossil has something a bit like that.

Can you elaborate how?

You can add text - essentially a wiki page - to a commit and edit it any time.

Additionally, you can also add tech notes, which are wiki-like entries in the timeline alongside commits.

Post reply on HN