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

341–350 of 406 posts

Re: My favourite Git commit (2019)

#341

Post by keybored »

neilkk wrote: post #256
keybored wrote: post #247

Earlier quoted context omitted.

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

But Github and similar tools actually solved this problem where Git failed to do so. Nowadays people have a setup with Github or bitbucket where they can navigate from a piece of code right to the pull request, where they can read the code review discussion, see the build log, reach linked resources like the Jira, etc.

“Just go to our web app” is not solving the same problem as what Git is trying to solve (the latter sometimes badly, it might be added).

Re: My favourite Git commit (2019)

#342

Post by schacon »

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…

To be clear from reading some of the other comments, I don't work at GitHub anymore so while I may have partially caused the issues I'm complaining about, I don't have the ability to fix them anymore.

Also, while most GUIs and editors have blame capability (as does GitHub actually), most of them don't ignore whitespace changes (-w), code movement or renames (the -C options) so they're often of limited use.

Finally, I _would_ like people to write good commit messages, I just would like to see a tool that actually uses that work in a way that helps document your code in an easy and valuable way, and the Git/Hub tooling makes that process at best "tedious" as someone in the thread says.

I am working on a new Git client called GitButler[1] and would like to address this at some point down the line, so maybe it ends up being me who helps fix this after all :)

1: https://gitbutler.com

Re: My favourite Git commit (2019)

#343

Post by JetSetIlly »

Izkata wrote: post #324
neilkk wrote: post #208

Earlier quoted context omitted.

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…

> If you simply want to comment the current state of the code, you should add a comment in the code. I think you mean "past state of the code"... These comments rarely get updated. My favorite recent one was several sentences describing a data structure and how it mapped out statuses, written about a decade ago. Barely a year after that comment and its code was written, the entire thing was re-written with completely…

The drifting of code from comments is a problem I would love to see solved.

I've seen tools that can compare the git commit dates of code with nearby comments and that's a good start. However, there are potential problems with that, such as code and the comments that discuss the code not being near each other; or the code being updated and there being no need to update the comment

I think literal programming might help here, but that's an entirely different topic really.

Looking for more advanced tools that that and I suppose we're into the world of AI - asking the tool to understand both the code and the comment and to compare the underlying meaning.

Code review is an option but outside of an organisation that's difficult to do and besides, I think the problem would be best solved by something that is repeatable and part of the build process. And I'd love to be able to have a git commit hook that can say, "hold on! you've updated code but there's a comment that now looks old". That's the dream.

Re: My favourite Git commit (2019)

#344

Post by metafunctor »

Izkata wrote: post #324
neilkk wrote: post #208

Earlier quoted context omitted.

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…

> If you simply want to comment the current state of the code, you should add a comment in the code. I think you mean "past state of the code"... These comments rarely get updated. My favorite recent one was several sentences describing a data structure and how it mapped out statuses, written about a decade ago. Barely a year after that comment and its code was written, the entire thing was re-written with completely…

Mistakes can happen. But if code comments are frequently not updated as the code evolves, it is a level of lazy that will probably manifest in other ways as well.

Re: My favourite Git commit (2019)

#345

Post by madsbuch »

floating-io wrote: post #149
madsbuch wrote: post #119

Earlier quoted context omitted.

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.

I would argue (rightly or wrongly) that there are two common truths to such a scenario: Scenario 1, you’re doing a bunch of small changes that work towards a larger purpose. They’re what I like to call “checkpoint commits”. They aren’t the whole story —- just a step along the way to whatever you’re trying to accomplish. Scenario 2, you’re coding instead of thinking. Making “random” changes until you get what you want…

None of these, the granularity of the changes are just smaller.

Yes, you could argue that we should go with preview envs and only merge larger changes into main. But then again, this adds considerable complexity to the infrastructure – something that might be merited when we scale to 10+ software engineers.

This is the nature of products where you work close with designers, POs, etc.

You simply don't don't do this effort to update text, positioning, colors, etc.

In particular: Remember that git is _not_ just for kernel-style projects.

Re: My favourite Git commit (2019)

#346

Post by palata »

gumby wrote: post #298
palata wrote: post #255

Earlier quoted context omitted.

> The key is not to put what you did in that first line, but why. Can't we just say that the key is to put something that makes sense for the first line, given that sometimes only the first line is printed? I don't really care if it says "The files must be in us-ascii" or "Changed the files to us-ascii"... both of them clearly tell me that the files were changed to us-ascii.

The difference is Chesterton's fence: when you encounter something seemingly pointless you should learn why it was there before you consider removing or changing it.

Ok, but when I read the first line of the commit, I am usually not considering removing or changing it. When I consider removing or changing the content of a commit, the least I can do is read the full commit description.

Re: My favourite Git commit (2019)

#347

Post by ayewo »

TheRealPomax wrote: post #228
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...)

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.

Re: My favourite Git commit (2019)

#348

Post by palata »

ParetoOptimal wrote: post #272
palata wrote: post #250

Earlier quoted context omitted.

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

Many engineers primarily or even exclusively use git via githubs interface and have never made a commit with a body.

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.

Re: My favourite Git commit (2019)

#349

Post by notfed »

mrinterweb wrote: post #139

This is the reason I dislike automatic squashing branches with rebase. Squashing discourages thoughtful and meaningful commit messages. What is the point of making a meaningful commit message for some specific change when it is just going to all be smashed together as a single commit on merge. I feel like rebasing is something that should be intentional to clean things up by the dev, but not as a default pattern on m…

Squashing is very useful....for local development.

The idea of squashing already-pushed commits frightens me, glad I've never had to deal with it. Where are they doing this?

Re: My favourite Git commit (2019)

#350

Post by madsbuch »

palata wrote: post #249
madsbuch wrote: post #119

Earlier quoted context omitted.

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

Like the sibling comment, this comment reads like a person who don't realise the breath of projects git are used for.

Not answering questions from my colleagues? No nee to be snarky, lets keep a good tone here.

Small refactorings is a good example of some code I would not write long commit messages. Like going through a function improving its clarity and adding comments – I would not redo that effort in the commit message. Text updates, style updates, etc. are also things that rarely merits big messages.

Great for you that you don't make 100 commits a day – but watch out that you don't mix disparate changes into a single commit.

Post reply on HN