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

221–230 of 406 posts

Re: My favourite Git commit (2019)

#221

Post by mixmastamyk »

brabel wrote: post #135
bradjohnson wrote: post #109

Earlier quoted context omitted.

IME git abstractions make it easy to read and navigate standard workflows, but incredibly difficult to repair issues that arise due to divergence of some kind or another because they are so opinionated. I use git 99% in the terminal, and 1% in some git tool for visualization, but I find that a lot of people use it in the opposite way and have problems working with others that use a very slightly different workflow. Y…

I don't have any problem at all, when some really tricky stuff needs to be done, I google for a solution and run whatever command magic I find. If you don't need to google for git commands to do uncommon things, I imagine you have a huge capacity to memorize things, good for you, but most of us don't. I do understand how git works and could use the CLI most of the time if I wanted to, but there's exactly zero reason…

Terminal for repeatability, gitlab for visualization is a good combo I’ve found. Push your branch and a great diff is waiting for you.

Re: My favourite Git commit (2019)

#222

Post by sunshowers »

madsbuch wrote: post #119
goku12 wrote: post #110

Earlier quoted context omitted.

I don't know how it's for everyone else, but I do value the body of the commits from others. It's true that I see only the subject line for most commits. But I eventually read the full body of commits I'm interested in. Honestly, it's frustrating when commit messages don't carry enough context. Sometimes that context fits in the subject line. For others, I expect an elaborate body.

On my work I make 1-15 commits a day. If I have to spend thought cycles on the commit message, that is time that goes from other productive endeavours. I think, as the original commenter also wrote, this might be worth it in much slower paces projects that is run in another cadence / over mailing lists. I particularly think that high paced application development do not benefit from git as documentation.

> On my work I make 1-15 commits a day. If I have to spend thought cycles on the commit message, that is time that goes from other productive endeavours.

I make roughly that many commits a day as well. If something's easy to understand I'll put in a simple commit message (e.g. [1]), but I do put in the effort for more complicated ones.

[1] https://github.com/nextest-rs/nextest/commit/efd194b2e1d8d61...

[2] https://github.com/oxidecomputer/omicron/commit/b07a8f593325...

Re: My favourite Git commit (2019)

#223

Post by dang »

Forge36 wrote: post #155

Previous discussion https://news.ycombinator.com/item?id=22519632

Thanks! Macroexpanded:

My favourite Git commit (2019) - https://news.ycombinator.com/item?id=22519632 - March 2020 (67 comments)

My Favourite Git Commit - https://news.ycombinator.com/item?id=21289827 - Oct 2019 (370 comments)

Re: My favourite Git commit (2019)

#224

Post by ajuc »

computerfriend wrote: post #91
ajuc wrote: post #41

I agree commit messages are the most important form of documentation. But I disagree about the format. I prefer commit messages like: JIRA-123 one-line 80-char-at-most description Long description if needed (but preferably keep it in JIRA).

Deeply strange to me that you can think that they're the "most important form of documentation" and then propose to put the documentation elsewhere.

JIRA contains more context than you can put in even most elaborate comment. For example links to duplicates, test cases, screenshots, core dumps, discussion with testers/customers, etc. And it's updated over time.

Would you change the commit message if a tester noticed something about your explanation of the bug was wrong but the fix still works?

Additionally the context is already there in the JIRA, retyping it in detail in a different format into the commit message is more friction for little benefit.

Re: My favourite Git commit (2019)

#225

Post by Sprocklem »

thrdbndndn wrote: post #97
masklinn wrote: post #49

Earlier quoted context omitted.

> I think the disadvantage with this style of documentation is you can't really alter the commit message after it's written. That is not a disadvantage. The commit is a historical record, if I come back to that commit 3 years later I want to know its purpose in the context it was in, I don’t want a whitewashed history. > Compare that with documentation stored in a .md file, or even a Wiki or even Confluence. My colle…

> That is not a disadvantage. The commit is a historical record OP's point is that, while commit message is indeed a historical record, documentation isn't (or shouldn't). If you double commit message as documentation, it would cause issues like wrong information confusing or misleading future readers because it's non-editable.

Crucially, however, the commit message is not documentation of the code, which would need to be changed and updated. Instead, it is documentation of the change, describing the reason for the change, what the code does to achieve that, and, if relevant, why you chose that solution. It provides necessary context to the already immutable diff and therefore need not be mutable itself.

Re: My favourite Git commit (2019)

#226

Post by wnoise »

kaashif wrote: post #201
ajuc wrote: post #43

Earlier quoted context omitted.

If you change a line of code without doing git-blame on it first you're doing it wrong. I've been bitten by this many times - I change obvious bug, I'm about to commit the changes, I see the previous commit which introduced the "bug" on purpose and the attached JIRA task has perfectly good explanation for why my obvious change would have reintroduced some bug from 2 years ago :)

> If you change a line of code without doing git-blame on it first you're doing it wrong. Working on a project where this is necessary sounds like a hellish experience. The place for comments explaining why the code is needed is right next to the code! On an adjacent line!

Why code is needed is different than why change is needed.

Re: My favourite Git commit (2019)

#227

Post by _Algernon_ »

mixmastamyk wrote: post #213
ChrisMarshallNY wrote: post #181

Earlier quoted context omitted.

This. I write documentation for me. Very few folks ever use my published code, which is fine by me. I publish it, because treating my packages as atomic, ship-ready, high-Quality products, forces me to take great care, in each and every one. Which means, when I use them in my other work, I don't have to worry about them. My take on documentation is thus: https://littlegreenviper.com/miscellany/leaving-a-legacy/

Documentation is for everyone. Put it where everyone can read it, not hidden in the most esoteric place possible, via a very unfriendly tool. I do that often and call it the developer guide. After the user and ops guides. Not to mention comment and doc strings about why in the current code.

This entire thread is making me feel like I'm taking a crazy pill.

A simple git log is considered "esoteric" these days? No extra command line arguments are required to read the entire commit message. If so software "engineering" is truly a dead discipline. I guess the "move fast and break things" crowd have taken over.

Re: My favourite Git commit (2019)

#228

Post by TheRealPomax »

mb7733 wrote: post #70
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…

Well, `git` is still the primary way I interact with a git repository, and `git log` shows the entire commit message by default. So I don't run into this problem. If some "modern" git frontend is only capable of displaying the first line of a commit message, then this is a problem with that tool, not git itself. (I'm also not convinced this is a limitation of all modern tooling...)

periodic reminder that `gitk` exists, and has come with git since... pretty much forever? If you're reading `git log`, you really owe it to yourself to run `gitk` at least once to see what you've been missing for over a decade now.

Re: My favourite Git commit (2019)

#229

Post by mostlylurks »

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…

I don't find it more difficult to use or remember commands for than remembering how to accomplish similar tasks in some GUI (especially if that GUI is emacs). And unlike most GUIs (emacs may be an exception), I can trust that my knowledge of the git CLI won't become out of date when my GUI tool inevitably undergoes a UI redesign of some sort.

But more importantly, the CLI allows my typical workflow where I chain together a bunch of git (and other) commands in a row, allowing me to just type in, for instance, several different commits, their messages, and what files should go into each in one go without having to break my concentration by having to move around in some GUI between commits. Sprinkle in some stash manipulation and interactive rebases, compilation, and unit testing, and you'll really start to see how the CLI allows you to offload some of your working memory to your invocation in a way that a GUI just can't.

Re: My favourite Git commit (2019)

#230

Post by krobelus »

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 problem is that Git was built so that the commit message is the _email body_, meant to be read by everyone in the project.

I find this very hard to believe. Isn't it "everyone who is interested in the commit subject/files touched should read the body". Why would anyone else read immutable historical documentation?

> 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.

This sounds like you are joking. Any good IDE will be able to annotate each line with blame info, and show the diff at the press of a button. On such diffs, the IDE should allow recursive blaming on context/deleted lines. Tools like Tig allow exactly that.

GitHub certainly does make it hard to see commit messages, I give you that :)

> Hundreds of hours of amazing documentation from a true genius that almost nobody will ever appreciate. It's horrifying.

?? It's not like it was written for fun. This documentation attached to a commit exists to reduce the risk of accepting the patch from someone who might not be around in future, to fix any problems introduced. By disclosing all their relevant thoughts, the author shows their good intentions: they enable others to build on top of their work. If the author kept their thoughts to themselves they would gradually build up exclusive ownership of the code, which is often not a good idea. Also a commit message serves as proof of work, which can be important when there's too many patches. For commercial projects some of this is less important.

Post reply on HN