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

351–360 of 406 posts

Re: My favourite Git commit (2019)

#351

Post by mrinterweb »

notfed wrote: post #349
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?

Github and Gitlab allow merge/pull requests to automatically squash on merge. Some teams set the squash merge strategy. My team used to squash by default, but I helped convince them otherwise.

Re: My favourite Git commit (2019)

#352

Post by madsbuch »

jonathanpglick wrote: post #163
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.

Until it's 7 years later, the original developers are gone, the ticketing system has changed twice, and you have no clue why something is the way it is. When you're committing is exactly when you already have the context of "why" loaded and even a short explanation should be quick to write. The thought cycles argument feels lazy unless you're doing a bunch of quick exploratory commits and clean up/squash your git his…

In that case, why should the commit history be the place to go? Commit histories are extremely exclusive – everybody not a part of the programming process will be locked out of that information. That is not fair.

Regardless, what you describe is more an organisational failure than an issue with commit messages.

Re: My favourite Git commit (2019)

#353

Post by mbork_pl »

yencabulator wrote: post #303
mbork_pl wrote: post #54

Earlier quoted context omitted.

Nice try, but the problem with this is that typography is _really_ complex. For example, there is a rule in English typography (I'm not sure if it's often used today though) that when you have a quotation spanning several paragraphs, you should put an _opening_ quote at the beginning of each paragraph – but only one _closing_ one at the end of the quote.

We've let go of other historical typographic and spelling conventions, it's time to let go of that one too.

It would be quite sad. Besides, it is not an arbitrary convention, it serves a purpose.

Re: My favourite Git commit (2019)

#354

Post by sverhagen »

u801e wrote: post #318
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.

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

Re: My favourite Git commit (2019)

#355

Post by palata »

madsbuch wrote: post #350
palata wrote: post #249

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

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

I didn't mean to be snarky, sorry if I read like that! I was trying to list examples of "non-coding" that I find are important :-).

> Small refactorings is a good example of some code I would not write long commit messages.

I totally agree! Now I am starting to think that we all agree here. I was just confused because your comment seemed to disagree with its parent, which says: "Sometimes that context fits in the subject line. For others, I expect an elaborate body".

But apparently you do agree with that: sometimes it is worth writing a long commit message, sometimes it is not. It depends on the situation, and then it's a matter of common sense/experience.

Re: My favourite Git commit (2019)

#356

Post by sverhagen »

js2 wrote: post #267
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…

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…

>Sometimes a comment is appropriate. Sometimes a commit message is appropriate. Sometimes I need both.

And often your get neither...

Re: My favourite Git commit (2019)

#357

Post by mbork_pl »

Izkata wrote: post #326
mbork_pl wrote: post #30

Earlier quoted context omitted.

How do you handle non-paired ones then?

I would base direction on adjacent whitespace/punctuation instead of trying to do pairing.

Nice try, too. How would you handle Spanish quotation marks at the beginning of the sentence, then? And what about French quotes which are separated from their contents by a thin space? All of that is possible, of course, with large tables of special cases.

Or, you know, you could just have separate characters for opening/closing quotation marks. ;-)

Re: My favourite Git commit (2019)

#358

Post by palata »

madsbuch wrote: post #352
jonathanpglick wrote: post #163

Earlier quoted context omitted.

Until it's 7 years later, the original developers are gone, the ticketing system has changed twice, and you have no clue why something is the way it is. When you're committing is exactly when you already have the context of "why" loaded and even a short explanation should be quick to write. The thought cycles argument feels lazy unless you're doing a bunch of quick exploratory commits and clean up/squash your git his…

In that case, why should the commit history be the place to go? Commit histories are extremely exclusive – everybody not a part of the programming process will be locked out of that information. That is not fair. Regardless, what you describe is more an organisational failure than an issue with commit messages.

> In that case, why should the commit history be the place to go?

In my experience with open source projects, the history is very much where I go. Say I read some code and don't understand a line (say it is weird, but it does not feel like complete garbage because the rest of the code is actually good), then I will definitely `git blame` or even start digging in the history to see where that line comes from.

Good commit messages have saved me more than once in that situation. It doesn't have to be a whole essay, but something meaningful. Something like "apparently Travis CI wants two white spaces here" is already useful: it says that back then, they used a CI called "Travis" and it required that weird extra space. Now I feel safe removing it because the project does not rely on Travis anymore. (For example).

Note: it could be in a comment. But comments rot, move, get out of sync, disappear. It's much harder to check all the revisions of a file in the last 7 years to look for a potential comment on another line than it is to find the commits that actually edited the line of code.

Re: My favourite Git commit (2019)

#359

Post by lawtalkinghuman »

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 reason people (myself included) rather like good Git commit messages is evident when one compares them to the alternative.

You're working in a commercial/closed source environment and want to find out why line 57 in src/blah/db/utils.py does that. Where do you look?

- inline code comments. Usually non-existent. Often out-of-date, sometimes misleading, frequently tells you no more than you can discern from just reading the code itself (especially now type annotations are trendy again). Rarely explains why the code exists. There's a reason people caution against too many comments, and that translates into people probably not putting enough commentsin.

- calling code? Helpful, but thanks to microservices and increased levels of abstraction (APIs, DI frameworks, messaging buses, config parsing) you've got to go check 900 different repos out to work out what is going on.

- email? Give up. You'll find invitations to the company Christmas party and Q2 sales figures but actual tech explanations are in short supply.

- Slack etc - same problems as email, plus developers who hide away all the interesting stuff in private team channels

- Google Docs - you probably don't have access to the relevant doc, and there's no way to know that you don't

- wiki/docs? Half baked, wrong etc. Or it'll be autogenerated JavaDoc type stuff that'll tell you what you already know or can reasonably infer from the code. Also, findability sucks. Or the developers just avoid the whole thing because the software is nasty and corporate and barely usuable.

- bug tracker/ticketing system? You ask around and someone says "oh yeah, Dave made that change two years ago" and then you search for tickets that match related keywords only to find out that those tickets weren't brought over from Trello into JIRA, and now you need to go ask IT to give you access to the legacy Trello board which they don't want to do because then it'll put them over the five users per month limit or whatever.

- Architecture Decision Records / decision logs / whatever you want to to call them - nice if they exist, I guess.

- ask the person who wrote it? This assumes they still work there and can remember. Plus you gotta do the asking around routine which takes days and destroys all hope and joy in the world.

By a process of elimination, commit messages are the closest you're going to get. They're right there - on your computer, neatly integrated into your editor, hopefully. You can search them fast in a terminal window rather than in some slow web-based monstrosity. If you're lucky, they're actually useful. Even if they aren't, they're at least contextually useful in helping you narrow down your search strategy for the inevitable plunge through email/slack/JIRA/Trello/internal wiki etc.

Ideally what should happen is the really useful commit messages get copied into stable technical documentation like decision logs or a properly maintaned wiki. If people did that, great, but it's pretty rare. A culture of sharing weird interesting tech things in a Slack-type system can help because future devs can at least search but you do that at the cost of more interruptions for colleagues now.

The broader issue is of all the bad options you can choose, it often tracks the wrong thing. In something like Trello/JIRA/whatever, if you're looking for the technical reasons, it'll have the business reasons without the technical stuff, or vice versa. You generally want both, and most systems only give you half the story.

Re: My favourite Git commit (2019)

#360

Post by goku12 »

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.

> If I have to spend thought cycles on the commit message, that is time that goes from other productive endeavours.

This is a bad excuse against writing proper commit messages, since it can be easily extended to user and development documentation. If you want to classify these as productive endeavors while commit messages as non-productive, it basically boils down to doing as little as possible that you can get away with.

> On my work I make 1-15 commits a day.

That is hardly hectic enough to avoid good commit messages. I have seen people writing good commit messages at much higher commit rates. Frankly, good commit messages are actually time savers if you have a high commit rates.

> I particularly think that high paced application development do not benefit from git as documentation.

Things like good commit messages and a lot of other best practices are completely avoidable in the name of high pace. However, the time savings are marginal compared to the quality you sacrifice.

Post reply on HN