Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Show HN: Tool to Automatically Create Organized Commits for PRs

github.com

Post reply on HN
Print view View original

11–20 of 54 posts

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

#11

Post by bredren »

This is a cool idea, though part of what keeps my work organized and my understanding of my own changes is to do the manual preparation of a series of logical commits.

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.

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

#13

Post by Fire-Dragon-DoL »

iandanforth wrote: post #2

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?

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

#15

Post by matijsvzuijlen »

CityOfThrowaway wrote: post #3

I haven't tried this yet (though I plan to). 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. T…

In such cases, I generally checkout main, do the side quest, and rebase my original branch on top of it. Then, I can just continue without waiting for the side quest to be merged. Depending on the situation, I may make a separate PR for the side quest, but I don't have to wait for it to get merged.

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.

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

#16

Post by baq »

Fire-Dragon-DoL wrote: post #13
iandanforth wrote: post #2

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?

If you need to use —-merges-only you might as well squash everything, why bother.

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

#17

Post by Fire-Dragon-DoL »

baq wrote: post #16
Fire-Dragon-DoL wrote: post #13

Earlier quoted context omitted.

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?

If you need to use —-merges-only you might as well squash everything, why bother.

I use merges-only when I need to look at the history "index" and I use the full history when I need to find out why a certain line was changed, kinda like a book has an index but there are also all the chapters with all the content

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

#18

Post by Cthulhu_ »

In our org we squash all commits into one anyway, the main commit title is based on the title of the merge request. We also have an AI code review tool set up (which I usually ignore because there's a lot of extraneous information) that suggests a new title, given that the people making the MR often don't consider that the title ends up in the changelog, becoming the one line that will be used by people using the library to decide whether they need to do something.

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

#19

Post by jaredsohn »

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.

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

#20

Post by figmert »

jaredsohn wrote: post #19

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?
Post reply on HN