Live data from Hacker News

Show HN: Tool to Automatically Create Organized Commits for PRs

github.com

21–30 of 54 posts

Re: Show HN: Tool to Automatically Create Organized Commits for PRs

#21
post #20

I didn't look at things too closely, but it would be nice if this each commit would include a ticket number from the branch (such as a linear id) and/or pr id in each commit for people who do not squash. 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.

Surely this would be the job of a prepare-commit-msg/commit-msg hook?

Yeah, could be a separate tool. Another tool could be a GitHub action that checks if the ids are in each commit; I built a prototype of that for work but it needs some polish and permission for a more general release.

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

Re: Show HN: Tool to Automatically Create Organized Commits for PRs

#23

Can I suggest, don't do this? The sustainable unit of code modification is the ticket, not the commit. When you're ready to merge to main, squash all commits into one that takes the ticket title as its commit message and appends the ticket description as its description. This aligns code changes with planned, scoped, and documented units of work. Anything more granular than that quickly becomes noise. By following th…

I don't get it. Assuming your commits have meaningful messages and description, why squashing them? You can use git log --merges-only (I think that's the arg name) and all the sub commit are hidden, however you can still search through them to get a clear idea of why something was refactored a certain way. So,where is the noise if it can be hidden but also used to get additional information on code changes?

In my experience, when people need to know what commit belongs to what code, is the IDE the main driver: you see the line of code in the editor and automatically know what commit introduced it (e.g., via the git integration in the gutter). Typically you want to know as well all the other lines of code that were committed together (e.g., what does it take to implement feature X? Ah yeah, all these 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)

Re: Show HN: Tool to Automatically Create Organized Commits for PRs

#25

Can I suggest, don't do this? The sustainable unit of code modification is the ticket, not the commit. When you're ready to merge to main, squash all commits into one that takes the ticket title as its commit message and appends the ticket description as its description. This aligns code changes with planned, scoped, and documented units of work. Anything more granular than that quickly becomes noise. By following th…

I don't agree with most of this but my good faith take is that my experience trends closer to your opinion the more stable and large a codebase is plus how dedicated and multidisciplinary the team is. I disagree the most for young, volatile projects with small eng-only teams that are responsible for many projects at once.

Re: Show HN: Tool to Automatically Create Organized Commits for PRs

#26
The idea in itself seems good, but I have a lot of hesitation due to the prompt used to rewrite the commit messages. Even looking at the example in the repo there’s this sycophantic, pompous way of describing mundane things that adds nothing, but only makes it harder to understand what has changed. The commits mentioned don’t "implement a complete auth system" and did not add "comprehensive test coverage". They added parts of an authentication system and some tests.

I’m all for proper commit messages, but only if they add clarity, not take it away.

Re: Show HN: Tool to Automatically Create Organized Commits for PRs

#27
I had a look through the tests, but it doesn’t seem you do any testing of of this does a good job or not?

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?

Re: Show HN: Tool to Automatically Create Organized Commits for PRs

#28

https://graphite.dev/ provides a way to stack PRs, it's been discussed on HN in the past (e.g. https://news.ycombinator.com/item?id=30681308 ).

At my company we use git squash PR merge strategy. This makes individual commits irrelevant, but PRs as a whole do. I use git town for stacked PRs. It's very nice to do another brunch when I've finished a logical stage, because small changes are reviewed and I merge often. When I have fixes, "git town sync" propagates up the stack automatically
Post reply on HN