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

261–270 of 406 posts

Re: My favourite Git commit (2019)

#261

Post by c0pium »

schacon wrote: post #83
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…

I feel like it's not a question of "doing your damn job". It's a question of what value can you expect to get from a particular investment. If blame is your tool and every line happens to be changed from a different blame invocation (is it "-w", "-w -C", "-C -C -C", etc), how do you learn the story of this block of code best? Maybe you then need to read a story _per line_ of code. But that's not actually worst case.…

Git visualization isn’t git’s job, providing primitives like blame for git visualizers is. If you use VSCode with gitlens (pycharm is similar), the exercise you just mentioned is trivial. Focus a line, get the correct blame. Click on that, view the commit history. Click from there, see the diff.

Re: My favourite Git commit (2019)

#262

Post by c0pium »

bastardoperator wrote: post #179
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…

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.

Because you don’t actually understand the subtleties of the side effects of that 40-character change and building intuition about it takes a paragraph.

It’s all fun and games until your codebase is >1,000,000 loc.

Re: My favourite Git commit (2019)

#263

Post by cerved »

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.

Using vim-fugitive it's

  :Git blame %

Re: My favourite Git commit (2019)

#264

Post by cerved »

zaptheimpaler wrote: post #108
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 half vindicated about my rant a few weeks ago[1] arguing that we should make commit messages as long as we like instead of the stupid 50 character or whatever limit. If enough people do that, maybe tools like GH will stop wrapping the message by default. Even if not, atleast the first line is usually easy to see in most tools by hovering over it or something. [1] https://news.ycombinator.com/item?id=38831282

Presumably you're referring to commit subjects.

And no, they should absolutely not be as long as you like. It breaks things

Re: My favourite Git commit (2019)

#265

Post by SamuelAdams »

nextaccountic wrote: post #112
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.

I love this concept. I always begin messages with the most actionable or important thing at the top, and the rest that follows is the context. Respect the time of others and don't bury the lede

You see this all the time in business proposals. Executive summary at the top, typically 2-3 paragraphs max. Manager summary, 1-2 pages. Engineer detailed overview, 3-10 pages. Anything else is an addendum.

Re: My favourite Git commit (2019)

#266

Post by winwhiz »

gregmac wrote: post #258
winwhiz wrote: post #151

Earlier quoted context omitted.

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…

Your fictional example is not a good comparison -- I just can't imagine the scenario where you need to explain to someone who doesn't know how to modify their path why they need to add something to it. For someone actually using git (and the CLI, at that) I'd expect to be able to say "oh, make sure git is in your path" and for them to understand how to check and set that, or at least be able to Google it and follow t…

Yeah, I think I conflated a git specific question from the GP and a more general CLI question, my bad.

The argument can be made the interfacing with git is bad whether with mouse or with keyboard. My git secret weapon is to ask myself how do I make git do this thing that is easy in Subversion or Fossil and then I do that thing and I write it down so I can do it again in X number of months.

Re: My favourite Git commit (2019)

#267

Post by js2 »

neilkk wrote: post #208
js2 wrote: post #107

Earlier quoted context omitted.

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…

The thing is that writing a good commit message for future people doing `git blame` is only worth it if it's a line of code which someone in the future will look at and need to know why it was changed from its previous form to the current form. If you simply want to comment the current state of the code, you should add a comment in the code. No one will ever need to know in the future why that particular space charac…

Sometimes a comment is appropriate. Sometimes a commit message is appropriate. Sometimes I need both. Often when dealing with legacy code I find neither. I'd be happy with either.

A commit message lets me tell a short story about a change that touches multiple locations in the code base. Maybe no one part of the change is all that tricky.

A commit message also allows me to explain why I'm making the change, whereas a comment may explain why the code is the way it is.

Commit messages and comments have overlapping use cases, but the Venn diagram is not a circle.

$0.02.

Re: My favourite Git commit (2019)

#269

Post by RustyRussell »

I was told by a recent contributor that my approach (i.e. requirement) to git messages is "unique". Apparently my Linux kernel background is showing, but all my commit messages look like the one shown here!

If about existing code, the comment belongs with the code. If it's a process thing (e.g. code that is removed or didn't work), it belongs in the commit.

Most importantly, while commit messages can reference issues for convenience, they MUST reproduce the critical details: GitHub is transient, git messages are not!

Re: My favourite Git commit (2019)

#270

Post by cozzyd »

kaashif wrote: post #193
erik_seaberg wrote: post #140

Earlier quoted context omitted.

Writing good commit messages is part of your job in the sense that no reviewer should be approving anything without them, knowing that you may or may not be available if it breaks next year at 3 AM.

I put that kind of thing in the pull request, since that's where the review happens. Every commit links back to a pull request, and people actually do refer back to it. Writing good documentation there is part of the job. No-one's going to ALSO write commit messages that no-one will see.

pull requests don't live in the repository (as far as I can tell...) and require you to use whatever online interface creates them.

Not sure whey e.g. Github Pull request merges don't include the entire pull request description in the merge commit message.

Post reply on HN