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

381–390 of 406 posts

Re: My favourite Git commit (2019)

#381

Post by TheRealPomax »

ayewo wrote: post #347
TheRealPomax wrote: post #228

Earlier quoted context omitted.

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.

Well, I’ve heard of gitk too but gitk is not available by default on my default installation of macOS so there’s that.

I'm not sure why anyone would use default installations of any developer tooling on Mac? Was the first thing you did when you finished initial startup on your mac not "install homebrew, then install the most up to date versions of git, python, etc. etc."?

Re: My favourite Git commit (2019)

#382

Post by u801e »

sverhagen wrote: post #354
u801e wrote: post #318

Earlier quoted context omitted.

> It's an awful shame that GitHub doesn't allow commenting on commit messages. You actually can comment on a commit itself. I'm in the habit on middle-clicking on the sha1 link of commits in a PR and looking at the commit itself. You can comment on lines in the commit, and there's a text area at the bottom where you can comment on the entire commit itself. I'll then follow up with making a comment on the PR linking t…

I don't think they were suggesting to review the individual commits, rather the (individual) commit messages. Commit messages are text, so you could have a similar line by line click-and-comment review interface as you already have for the code changes.

> I don't think they were suggesting to review the individual commits, rather the (individual) commit messages.

That's a good point.

> Commit messages are text, so you could have a similar line by line click-and-comment review interface as you already have for the code changes.

It would be nice if something like that was available in Github. The closest thing you could do would be to copy the commit title and body and paste it as quoted text in the text area and then comment on it inline.

Re: My favourite Git commit (2019)

#383

Post by ben_w »

WalterBright wrote: post #309
tomjakubowski wrote: post #300

Earlier quoted context omitted.

How does your scheme handle Turkish "Dotless I"? Should there be different codepoints for serif and sans-serif versions of the same letter? After all, in some typefaces, "uppercase I" and "lowercase L" look just about the same.

I think you mean fonts. No, Unicode should not encode fonts. Nor should it encode italic, boldface, underline, line out, reverse video, point size, superscript, subscript, or colored. Those are all style attributes, best applied with a style sheet, not a code point.

> superscript, subscript

Very strongly disagree. Copy-pasting 106 turns into 106 rather than 10⁶.

Re: My favourite Git commit (2019)

#384

Post by palata »

ParetoOptimal wrote: post #377
palata wrote: post #348

Earlier quoted context omitted.

Right, but then maybe the main issue is those engineers, and not the tooling? When I see someone using a hammer the wrong way, I don't usually blame the hammer.

The problem is the network effects. If enough people start hammering with the side to pull out nails, like 95%, there's a chance that could become known as "the right way". I think a lot of the "get shit done" crowd for instance sees using Github and not "futzing around with git" as the right way to do things for getting shit done.

Sure, but because "the majority thinks it is the right way" does not mean it is. My point is that when the majority of people don't know how the most basic tool they use is meant to be used, then it is a problem.

It would still be better to say "I know how a hammer is meant to be used, but I choose to use it this other way", but that is not the situation right now. The situation right now is that more and more devs don't know that git != GitHub. And that inequality is an objective fact, it has nothing to do with network effects.

Everybody believing that the Earth is flat would not make it flat.

Re: My favourite Git commit (2019)

#385

Post by atq2119 »

michaelcampbell wrote: post #369
atq2119 wrote: post #313

Earlier quoted context omitted.

Then don't write commit messages for the future, write them for reviewers. Seriously, as somebody who reviews a lot of code, well-written commit messages are a godsend. It's an awful shame that GitHub doesn't allow commenting on commit messages. It's as if GitHub is being run by people who just don't know how Git is meant to be used.

> Seriously, as somebody who reviews a lot of code, well-written commit messages are a godsend. This is the issue; are commits in your codebase for the reviewers? Or for FutureDev to see what the hell happened? These are often very different things, and most process models favor one of these at the total expense of the other.

Interesting that you perceive a dichotomy there, can you elaborate where you see the conflict?

As a reviewer, I see myself as a (extremely near, time T+epsilon) future developer who is trying to see what the hell is happening.

Re: My favourite Git commit (2019)

#386

Post by kaashif »

ajuc wrote: post #220
kaashif wrote: post #201

Earlier quoted context omitted.

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

> a hellish experience. It's literally 1 click away. Or even just a hover over the margin. > The place for comments explaining why the code is needed is right next to the code! On an adjacent line! And then you refactor the code (from another place) and the function name and parameters change but the comments in adjacent lines remain the same. Ups, the comments lie. After enough time passes it's 50-50 whether a parti…

I'm not saying using git blame is hellish, I'm saying always needing to do it because of all of the things you described sounds hellish.

The original comment was that you should always do it, for every line of code.

Re: My favourite Git commit (2019)

#387

Post by nequo »

colelyman wrote: post #329
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…

One tool that I think promotes commit messages like the OP is magit in Emacs. Before using magit, I always used `git commit -m '...'` and didn't realize that commit messages could be longer than a line. I agree that this is a tooling problem, but magit is a breath of fresh air in many ways (including verbose commit messages).

What I like about magit is that it shows me the diff of the would-be commit when I write the commit message. And also that I can pick which sections of the diff to a file I want to include in the commit.

I used Vim + git CLI before and this was much less convenient. (I never tried fugitive though. It might be similarly great on these two features.)

Re: My favourite Git commit (2019)

#389

Post by FrederickZh »

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…

> Everything they talk about in this article is what is great about the _rest_ of the commit message, which, given modern tools, is _almost never_ seen by anyone.

This was why I created gh-ph [1].

[1] https://github.com/Frederick888/gh-ph

Re: My favourite Git commit (2019)

#390

Post by michaelcampbell »

atq2119 wrote: post #385
michaelcampbell wrote: post #369

Earlier quoted context omitted.

> Seriously, as somebody who reviews a lot of code, well-written commit messages are a godsend. This is the issue; are commits in your codebase for the reviewers? Or for FutureDev to see what the hell happened? These are often very different things, and most process models favor one of these at the total expense of the other.

Interesting that you perceive a dichotomy there, can you elaborate where you see the conflict? As a reviewer, I see myself as a (extremely near, time T+epsilon) future developer who is trying to see what the hell is happening.

There's a dichotomy between a history of actual code changes, oopsies and redos included, and "a carefully crafted story of the intent of this change". One is an ugly reality, the other is a pretty story of intention. The process vs. the final result.

Both are useful, but in different contexts. The latter is good for a PR, but when optimized for that often loses a lot of other context, and is meant to be a throwaway bit of data that once the PR is approved, never seen again, nor meant to be seen again.

The former can delve a bit into what experiments were tried and abandoned and can give a lot more meaning to the final result.

> As a reviewer, I see myself as a (extremely near, time T+epsilon) future developer who is trying to see what the hell is happening

I generally find this to not be the case; reviewing is to see what this might "break" and has IME been extremely transactional.

Not all PRs nor reviewers are like this of course, and you may not be one. But, again, IME, this is the "modern" workflow.

Post reply on HN