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

241–250 of 406 posts

Re: My favourite Git commit (2019)

#241

Post by winwhiz »

marwis wrote: post #175
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…

On Windows it's actually just: 1. Press Win key 2. Type env 3. Choose system or account

Thanks! This is what I was secretly hoping for. I am doing this a lot lately.

Re: My favourite Git commit (2019)

#242

Post by da_chicken »

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 issue is that most of the tooling (in Git or GitHub or whatever) generally only shows the first line.

This has been an issue with version control tooling for quite a long time. I'm fairly certain both CVS and SVN did the same thing. But I agree that you're still right.

I'm also very amused by the number of replies to your comment along the lines of, "oh, it's actually very easy because I always use ".

Which is, of course, rather proving the point.

Re: My favourite Git commit (2019)

#243

Post by twosdai »

masklinn wrote: post #49
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…

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

Sucks when you mess up in your commit message though and don't type the right thing.

Re: My favourite Git commit (2019)

#244

Post by dragonwriter »

da_chicken wrote: post #242
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 issue is that most of the tooling (in Git or GitHub or whatever) generally only shows the first line. This has been an issue with version control tooling for quite a long time. I'm fairly certain both CVS and SVN did the same thing. But I agree that you're still right. I'm also very amused by the number of replies to your comment along the lines of, "oh, it's actually very easy because I always use ". Whic…

No, because the point is about common tooling, and the common tooling does not, actually, make this difficult.

Re: My favourite Git commit (2019)

#245

Post by fishyjoe »

dblitt wrote: post #26
selimthegrim wrote: post #19

Earlier quoted context omitted.

I think this pops up in MacOS shells too

IIRC TextEdit.app has options like smart quotes, auto capitalize, and spell check turned on (in addition to being rich text by default), so you have to change all those to be a dumb plain text editor.

TextEdit and the Notes app have both caused me to copy/paste the specialized quotation marks.

Now I only use vim as a scratchpad because I've been bitten too much by GUI apps

Re: My favourite Git commit (2019)

#246

Post by mrinterweb »

bspammer wrote: post #57
tuetuopay wrote: post #45

Earlier quoted context omitted.

I despise squashs. It encourages people to tread git commit as a glorified ^S of their work. You want to know why a change was made, or who so that they can explain it. You land on a blob of a diff, with no meaningful commit message (any commit message was squashed to /dev/null to be replaced with the MR title and description). And then off you go to the corresponding github/gitlab/whatever MR only to find a wall of…

This is a false dichotomy. Someone creating the "fix problem" commits is not going to suddenly write great commit messages because the merge strategy changed. The root evil is actually MRs that live longer than a day or two, and change too much code at once.

Sometimes units of work that a branch would reflect are larger. I agree there are some branches that grow larger than they should, but often there are branches that involve a good number of changes, and breaking it into smaller branches doesn't really make sense either. There will always be branches where there should be multiple meaningful commits, and automatically squashing them all together just defeats the purpose of good commit messages. I don't buy into the idea that branches should always have just one commit or be reflected as a single commit on merge.

Re: My favourite Git commit (2019)

#247

Post by keybored »

schacon wrote: post #71
codemac wrote: post #65

Earlier quoted context omitted.

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…

Is it great for historical research? I feel like the format and tooling around it is uniquely _not great_ for historical research. I think it's optimized for discussions before integration, which is largely what PR descriptions and comments are largely used for now. I feel like given great commit messages, determining a story and useful history around any block of code given the Git tooling is incredibly difficult ev…

> I think it's optimized for discussions before integration, which is largely what PR descriptions and comments are largely used for now.

As a GitHub co-founder, whose fault is that? I have seen many great PR descriptions on GitHub that never make their way into the final inclusion in the main/master git history.

Meanwhile the git project links every commit to the message id whence the original patch (for many years now—not the whole history). Which will be available as long as the email archives are out there somewhere.

And the commit messages get reviewed into a good shape. Something that I’ve never seen anyone do on GitHub.

Re: My favourite Git commit (2019)

#248

Post by keybored »

schacon wrote: post #94
mb7733 wrote: post #70

Earlier quoted context omitted.

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

I can't tell if this is engaging with trolls or not, but I can't imagine that all of your interactions with your codebase are via `git log` with no other flags. Even the with the normal Git CLI that most of us use daily, most of us use `--oneline` or whatever to simplify useful calculations and visualizations like `--graph`, etc. But we're talking here mostly about code archeology, learning about the history of a blo…

> I can't tell if this is engaging with trolls or not, […] that most of us use daily, most of us use `--oneline`

You speculate that someone who uses git log without listing (or complaining about) all their flags are a troll?

Re: My favourite Git commit (2019)

#249

Post by palata »

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.

Do you apply that to everything? Like not answering questions from your colleagues, not writing test, not refactoring, not optimizing, etc?

I personally don't measure my productivity by the number of commits I push. If I did, I could easily make 100 commits a day. And there of course it would be better for me to not care about the commit description, because it would take thought cycles and anyway the commits would make no sense.

Re: My favourite Git commit (2019)

#250

Post by palata »

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 issue is that most of the tooling (in Git or GitHub or whatever) generally only shows the first line.

Maybe I do it wrong, but the most basic interface I use to check the git history is `git log`, which shows the whole commit message.

GitHub takes me 18 clicks to find the commits, I don't see why I would even bother using it.

Post reply on HN