31–40 of 54 posts
> 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.
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
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.
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 ).
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
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
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…
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.
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…
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.
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
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'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…
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.
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.