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

41–50 of 54 posts

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

#41

Post by claytonjy »

f1shy wrote: post #34
nrvn wrote: post #31

In my org I have enforced linear history, squashing all commits into one in PRs and roughly following the rule from [1]: > 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. [1]: https://go.dev/doc/contribute#review

Always squashing is a terrible idea. Where I work are some that insist in doing that, and already dozens of times we have los valuable information. Let me quasi-cite somebody with some knowledge about git: 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 d…

I used to like allowing squashing or fast-forward merges. Most PRs would be squashed, because most developers write terrible commit messages and use merge where they could rebase. But, if you had a well-crafted set of commits, we could retain them.

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

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

#42

Post by [deleted] »

nrvn wrote: post #31

In my org I have enforced linear history, squashing all commits into one in PRs and roughly following the rule from [1]: > 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. [1]: https://go.dev/doc/contribute#review

[deleted]

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

#44

Post by trust_bt_verify »

diggan wrote: post #37
scottgg wrote: post #10

Since moving to jj[1] as a git-compatible alternative, I’ve found it so easy to make clean commits I do it by default for everything - usually 1/ refactor 2/impl, 3/ docs. Because you can always just “jj new” on top of an existing change then squash it down and get automatic rebase past that point it’s quick to keep things organised and makes review life suck less. [1] https://github.com/jj-vcs/jj

> you can always just “jj new” on top of an existing change then squash it down and get automatic rebase past that point 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.

Sounds like it may be closer to ‘git commit —fixup HEAD’ but same idea.

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

#45

Post by scottgg »

diggan wrote: post #37
scottgg wrote: post #10

Since moving to jj[1] as a git-compatible alternative, I’ve found it so easy to make clean commits I do it by default for everything - usually 1/ refactor 2/impl, 3/ docs. Because you can always just “jj new” on top of an existing change then squash it down and get automatic rebase past that point it’s quick to keep things organised and makes review life suck less. [1] https://github.com/jj-vcs/jj

> you can always just “jj new” on top of an existing change then squash it down and get automatic rebase past that point 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.

You can do it to any change in the repo and everything gets automatically rebased downstream of it - so if you three nicely structured changes you can go change the first one if you need and it just works.

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.

[1] https://steveklabnik.github.io/jujutsu-tutorial/

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

#47

Post by diggan »

scottgg wrote: post #45
diggan wrote: post #37

Earlier quoted context omitted.

> you can always just “jj new” on top of an existing change then squash it down and get automatic rebase past that point 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.

You can do it to any change in the repo and everything gets automatically rebased downstream of it - so if you three nicely structured changes you can go change the first one if you need and it just works. 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. [1] https://steveklabnik.git…

> You can do it to any change in the repo and everything gets automatically rebased downstream of it

So does `git rebase -i $commit^1` and marking the commit with `edit`, any commit afterwards (which I think you mean by "downstream"?) also gets rewritten since you've changed a commit in the middle.

I'm not sure if you're selling it a bit short, or if `jj` just have a target audience that I am not a part of, both are of course ok :)

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

#48

Post by yencabulator »

diggan wrote: post #37
scottgg wrote: post #10

Since moving to jj[1] as a git-compatible alternative, I’ve found it so easy to make clean commits I do it by default for everything - usually 1/ refactor 2/impl, 3/ docs. Because you can always just “jj new” on top of an existing change then squash it down and get automatic rebase past that point it’s quick to keep things organised and makes review life suck less. [1] https://github.com/jj-vcs/jj

> you can always just “jj new” on top of an existing change then squash it down and get automatic rebase past that point 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 have yet to see anything in jj that isn't also a git operation, they're just emphasized and exposed differently, and the gg GUI makes some things more intuitive (and also makes screwing up your history accidentally much easier).

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

#49

Post by yencabulator »

jon-wood wrote: post #32
h1fra wrote: post #29

I'll never understand people caring about commit in PRs, just push whatever and squash at the end. If commit matters that means you should have done multiple PRs

And I will never understand people not caring about commits and just going "we'll squash it all anyway". I think of these things as different levels of granularity, the PR is a complete feature, while the commits are the steps taken to get to that feature. By splitting your PR into coherent commits you make review easier by allowing each commit to be reviewed in isolation. It will forever infuriate me that Github's c…

It's the difference between people who have had to troubleshoot obscure problems in complex systems and people who haven't.. Software archeology is important.

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.

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

#50

Post by martinvonz »

yencabulator wrote: post #48
diggan wrote: post #37

Earlier quoted context omitted.

> you can always just “jj new” on top of an existing change then squash it down and get automatic rebase past that point 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 have yet to see anything in jj that isn't also a git operation, they're just emphasized and exposed differently, and the gg GUI makes some things more intuitive (and also makes screwing up your history accidentally much easier).

In some sense, every jj command does more than any single git command because they implicitly amend the working-copy commit and rebase any descendants on top.

Another example is `jj rebase -d main`. It may look very similar to `git rebase main`, but it rebases a whole tree. See https://stackoverflow.com/questions/17315285/rebasing-a-tree... if you don't know what I mean.

Another example is `jj squash --from main..my-branch --into my-other-branch some/path`, which removes all the changes to `some/path` that happen in any commits in `main..my-branch` and squashes them into the tip commit of `my-other-branch`.

Does that help? I'm not sure I understood your comment correctly.

Post reply on HN