undefined

points

[-]

Not GP, but in my experience, those small changes are usually contrived to be small. Like saving snapshots instead of being atomic and self contained. And if they are the latter, they should have been separate PR.

That’s why I usually look at the diff of the whole PR and prefer to merge by squashing. Commits inside the PR are usually noise.

by soon_to_be_sb12 hours ago|

parent|

[-]

What you are saying is true if created manually. It is a chore to create sensible commits messages when you are committing often.

But LLMs appear to be pretty good at making small commits with sensible commit messages, that greatly help to make sense of the whole PR.

Regarding large monolithic commits, how do you even know where to start reviewing in a large PR? Smaller commits at least give you some sense of ordering.

by skydhash9 hours ago|

parent|

[-]

> Regarding large monolithic commits, how do you even know where to start reviewing in a large PR?

What I’m saying is that large commits shouldn’t be a thing without out of band discussions (formatting, design refactoring, features merging). With such knowledge, it’s easy to glance at the code and understand the implementation.

by soon_to_be_sb23 minutes ago|

parent|

[-]

>without out of band discussions..

Not every project can afford this.

>With such knowledge, it’s easy to glance at the code and understand the implementation.

I really doubt that this is true for large, legacy code bases, where one is only familiar with a small part of the system.