4 ms·

Perfect for [...] improving repository maintainability. This misses the whole point of using commit messages to record intent. At least with a bunch of "fixed

by cube00 1y ago

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.

fka 1y ago
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.
- MangoToupe 1y ago
  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.
  - fka 1y ago
    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.
- cube00 1y ago
  > 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.
  - jghn 1y ago
    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.
    - cube00 1y ago
      > 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.
    - accoil 1y ago
      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.
  - milkey_mouse 1y ago
    > 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?
    - deleted 1y ago
      [deleted]
    - cube00 1y ago
      > 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.
acjohnson55 1y ago
I'm guessing that the intent is deducible from the diff a pretty large percentage of the time.
- amake 1y ago
  Really? Almost always I feel the diff captures only the how, not the why.
- cube00 1y ago
  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 https://news.ycombinator.com/item?id=45871258 [2]: https://github.com/f/git-rewrite-commits/commit/210ada7ec78fa0fc9295d713772b20470cb947ae https://github.com/f/git-rewrite-commits/commit/210ada7ec78f...
nikeee 1y ago
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.

by cube00 1y ago

fka 1y ago

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.

MangoToupe 1y ago
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.
- fka 1y ago
  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.
cube00 1y ago
> 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.
- jghn 1y ago
  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.
  - cube00 1y ago
    > 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.
  - accoil 1y ago
    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.
- milkey_mouse 1y ago
  > 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?
  - deleted 1y ago
    [deleted]
  - cube00 1y ago
    > 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.

acjohnson55 1y ago

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

amake 1y ago
Really? Almost always I feel the diff captures only the how, not the why.
cube00 1y ago
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 https://news.ycombinator.com/item?id=45871258 [2]: https://github.com/f/git-rewrite-commits/commit/210ada7ec78fa0fc9295d713772b20470cb947ae https://github.com/f/git-rewrite-commits/commit/210ada7ec78f...

nikeee 1y ago

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.