Hacker News Reader

Comment by cube00 | Hacker News Reader

Perfect for [...] improving repository maintainability.

This misses the whole point of using commit messages to record intent.

At least with a bunch of "fixed it" commits I know what I'm in for. This only fools yourself and others into thinking the repository was well maintained.

View on HN

Yeah, "fixed it" doesn't provide any information that might be hallucinated.

Please don't use AI-generated commit messages blindly. Instead, use AI later when reading commit messages. It will have more context (following commits) to see what was actually happening. Having to guess whether a message was hallucinated by an AI won't help. If the message conflicts in its intention with what it isactually doing, you can spot the bug. You won't get that with AI messages.

Also, using AI commit messages will freeze it's capabilities in time, when creating the commit. When using AI at reading commit messages, you'll always get the latest options for analyzing the commits.

Just because it has more text doesn't make it a better message.

Good point. The purpose of git-rewrite-commits isn’t to "polish" history or rewrite meaning, it’s more of a rescue tool for those chaotic early stages of side projects (like mine) where commits are basically "update again" for months.

In those cases, the "intent" was never recorded in the first place, so the AI is just giving some structure and readability to what’s already lost context.

It’s not about pretending the repo was well maintained, it’s about making messy histories a bit more understandable for humans (and future me) without rewriting the actual code or meaning.

I think that's perfectly fine on a branch. I don't see this being deploying on the main branches of any projects of note.

Agreed! I've already added several warnings and disclaimers to the README :) It's really meant to be a "use it once or twice in your lifetime" kind of tool, not something to run on every project. Actually, mostly shouldn't.

> those chaotic early stages of side projects (like mine) where commits are basically "update again" for months.

I don't accept "chaotic early stages of side projects" is a justification for skipping out on writing good quality commit messages.

It wouldn't be acceptable in a well managed company so I don't understand why side projects would get a pass to become sloppy.

It's your side project and you're free to skip writing commit messages, but you need to own that decision and not blame "those chaotic early stages"

I've found taking the time to write good commit messages helps me as I can see what I've tried previously and pull out any older versions if I've found a new direction isn't working for me. It also captures my thought process in case I'm tempted to repeat the sins of the past.

Not all git messages are equal. My $0.02 is that commit messages I write are for other people. Until I officially hand a branch over for other people's consumption, like a PR, if I'm committing the only reason is because I want to access my code on another machine. I'll put whatever junk I please in those commit messages. But then before I open a PR I'll collapse everything down into 1+ commits each with curated content and appropriate messages.

> My $0.02 is that commit messages I write are for other people.

I write them for my future self.

In this context we're talking about a side project which presumably won't have a PR where the commit messages are cleaned up (at least I don't do PRs for my own side projects).

If I'm on a branch then I will write junk commits and clean them up before merging to main if I actually manage to get the feature right.

This project shows that git messages aren't just for other people as it's an attempt to make terrible messages usable for the person who wrote the code in the first place.

> It wouldn't be acceptable in a well managed company so I don't understand why side projects would get a pass to become sloppy.

Because no one's paying you, and you owe your users nothing?

> Because no one's paying you

While I'm certainly getting there, I'm not cynical enough to believe being paid is the only reason to take pride in the quality of your work.

Ha! I practice good commit hygiene---even when no one's paying me---because it's useful to my future self, but I don't think pride in one's work (especially through importing workplace best practices) is a great reason, especially not a normative one. I think this is like the proverbial carpenter finishing the back of a drawer though no one will see it. It's done for the carpenter's sake, out of principle or mundane Calvinism, and I wouldn't begrudge a carpenter who didn't. And the latter might sell more furniture.

But yeah, if someone made a cabinet with fancy Japanese joinery that turns out to be inkjet AI-generated veneers over glue and nails... I would not buy it.

I don't think that's the idea; it's more that when you're not beholden to an employer, you can focus on (and take pride in) whichever aspects of the work you want to focus on. When I'm working on my own projects, most of the pride I take in my code is based on what it does -- not on how clean it is, and certainly not on how well organised is the repository it lives in.

Yes, sometimes that makes things harder in the long run, but on the other hand there may not be a long run for this project if I try to force myself to do all the tedious bits 'correctly'. (And 99% of the time what bites me is my sloppy coding practices; it's very rare for much to hinge on the quality of my commit messages.)

I think it’s a great justification. It’s a side project. It’s supposed to be fun. If you hate writing commit messages, though, of course you can always just commit with the amend option and force push. But in general I think side projects are better the fewer rules they have.

> It wouldn't be acceptable in a well managed company so I don't understand why side projects would get a pass to become sloppy.

I can assure you that it's very acceptable at companies of all sizes and ironically it's the most senior most experienced people who write "flerpin derpin" as commit messages.

Sorry, but this holier than thou attitude is silly. If you’re working on a side project after your kids are in bed and you want to write “did stuff” as your commit message, you don’t have to feel like you’ve committed a sin.

Git commit messages are nothing to obsess about. If you're worrying about a "messy" git commit history, you're not moving forward, you're stuck in the past, and that indicates bigger problems. The only thing that really matters to me is the state of the code today, not 500 git commits ago. But I don't know what kind of work you do, I just know I don't have time to obsess about anyone's git commits from weeks or months ago. I just know where the code is today, and where I need it to be in the next iteration. Sure, write a basic commit message, but don't waste time on it. And don't obsess about "rebuild" commits or whatever extraneous thing that needs a commit. It isn't going to matter if you're always moving forward.

500 commits ago was 10 commits ago at some point in time. And it can be 5 commits ago for part of the code. Imagine looking ar some function and wanting to know why a particular step exists. It’s easy to do a quick blame, then find out it was modified in 2020 to fix some issue. Then quicky scan the message and diff to capture the reasoning behind the change.

That is why good summary and atomic commits are important. They exist in the time dimension.

None of that has ever, in 40 years of programming, been very important to me. Again, the only thing that really matters to me is the state of the code today, and the direction the code needs to go in. Where the code has been simply doesn't matter very much to me (YMMV). Git commit history has had so little value to me in practice that it's almost completely pointless to worry about. But again, YMMV.

I'm guessing that the intent is deducible from the diff a pretty large percentage of the time.

Really? Almost always I feel the diff captures only the how, not the why.

I didn't find it too deducible when OP removed the acknowledgements section after another commenter called them out on the AI slop [1]

docs(readme): remove acknowledgments section [2]

[1]: https://news.ycombinator.com/item?id=45871258

[2]: https://github.com/f/git-rewrite-commits/commit/210ada7ec78f...

Reply on news.ycombinator.com