The tool sends the diff of your git branch against a base branch to an LLM provider. The LLM provider responds with a set of suggested commits with sensible commit messages, change groupings, and descriptions. When you explicitly accept the proposed changes, the tool re-writes the commit history on your branch to match the LLM's suggestion. Then you can force push your branch to your remote to make it match.
The default AI provider is your locally running Ollama server. Cloud providers can be explicitly configured via CLI argument or in a config file, but keeping local models as the default helps to protect against unintentional data sharing. The tool always creates a backup branch in case you need to easily revert in case of changing your mind or an error in commit re-writing. Note that re-writing commit history to a remote branch requires a force push, which is something your team/org will need to be ok with. As long as you are working on a feature branch this is usually fine, but it's always worth checking if you are not sure.
I’m all for proper commit messages, but only if they add clarity, not take it away.
Since models reacts so differently to different prompts, and people have different requirements, I feel like a basic requirement for a generally useful tool using LLMs should at least facilitate overriding both the system and user prompts wherever they're being used.
I remember coming across this with Aider as well, and seeing some things that were out of place (for me) in the prompts, but with no way of changing it, I had to rewire things myself so I could override them.
Never used jj, but isn't that just `git commit --amend`? Lets you add/remove/change changes from the previous commit by basically overwritting it with a new changeset+message.
I’m selling it short a bit - it does a lot more! There’s a great Steve Klabnik tutorial [1]. To me the main thing is it makes it very easy to think and work in terms of logical changes.
I’m fine that people squash as long the reasoning is recorded in comments and reflected through automated tests (unit AND system/api).
This is also crucial information for AI coding tools.
I make use of interactive partial commits using Pycharm when a single file has changes related to different ideas and rewrite history for clarity.
It does matter to me if someone else has gone to this trouble. And it is sometimes a tip off if a person is seemingly sloppy in commit history.
It makes sense that this project exists but I’m also glad it didn’t when I was learning to work in professional environments.
One thing I would love is if I could give it a hint and have it extract out certain types of changes into its own branch that could split into a new PR.
I often find myself adding a new, re-usable component or doing a small refactor in the middle of a project. When you're a few commits into a project and start doing side-quests, it's super annoying to untangle that work.
The options are one of:
1. A mega PR (which everybody hates) 2. Methodologically untangling the side quest post-hoc 3. Not doing it
In principle, the "right" thing to do would be to go checkout main, do the side quest, get it merged and then continue.
But that's annoying and I'd rather just jam through, have AI untangle it, and then stack the commits (ala Graphite).
It's easy to verbally explain what stuff is side-quest vs. main quest but it's super annoying to actually do the untangling.
Maybe this tool magically can do that... but I do wonder if some context hints from the dev would help / make it more effective.
Alternatively, if you don't like rebasing, you can merge the side quest branch into your project branch instead.
Either way, you don't have to wait for the side quest to get merged.
How did you collate hundreds or thousands of examples of commits being split up and how did you score the results LLMs gave you? Or did it take more than that?
One huge advantage of squashing branches is if you see a commit in a `git blame` you might have an idea of where it came from within GitHub/Linear/other systems.
Think these tools together make non-squash PRs much easier to deal with for people who don't want to spend the extra time tidying things up.
BTW, really excited to see this. I was thinking about the concept in a thread last year https://news.ycombinator.com/context?id=40765134
"I look forward to the day that I can run a local LLM (for confidentiality reasons) to automatically reorganize commits within my PR. Should be very safe compared to generating code or merging/rebasing other code since it is just changing the grouping of commits and the final code should be unchanged."
You can also use the --instructions param for this tool to name commits via the LLM.
So,where is the noise if it can be hidden but also used to get additional information on code changes?
I couldn’t care less what changes were introduced in a particular commit (what for? Debugging? Your features should be small enough that debugging them shouldn’t be a pita anyway)
1. Always squash and merge 2. But have tidy commits 3. So your squashed commit has a useful list of what is in the commit
I think the intent is that it be up to the org to decide whether they’ll accept a stream of commits to merge or squash merge after approval.
> If the request is accepted, all commits will be squashed, and the final commit description will be composed by concatenating the pull request's title and description.
One less thing to think about.
Less is more, not vice versa.
Linus Torvalds generally prefers not to squash commits when merging pull requests into the Linux kernel, especially when the individual commits have valuable information or context. He believes that squashing can discard useful history and make it harder to understand the evolution of the code. However, he also acknowledges that squashing can be useful in certain situations, such as when dealing with a large number of commits that are not relevant to the main development history
But - I also think that always squashing is a natural reaction to "twiddling with the past" being difficult (but possible!) with git - e.g., you start with good intentions, you have your nice commit messages, but inevitably you need to go back and make some changes to changes and the "chore: unfuck it for real this time" style "fixup" commits start creeping in and you throw your hands in the air in despair rather than dare to cross `git rebase` once more.
I’ve recently switched to using conventional commits and release-please everywhere, but that pretty much forces us into a squash-only world, since even the devs who write nice commit messages don’t want to make each commit a conventional commit; much nicer to do it as the PR title, and more visible
It will forever infuriate me that Github's code review UI buries commits in favour of a big blob of changes without context, more so because that UI is generally considered Good Enough by most people, discouraging any innovation around code review.
I think graphite.dev is the most well-known, but I’m also a fan of others reviewable.io and codepeer.com … I know this space well because I made codeapprove.com to improve code review on GitHub.
My personal route: clean atomic commits that do one thing at a time and are justifiable on their own, rebased to minimize small-scale concurrent branches littering the history.
