Yes, why should we do the things in easier and more comfortabke way (review small changes) when we can force user into harder one (newest changes mixed with all previous ones).
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.
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.
> 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.
You expect to send a big PR to someone without him being aware of the context or without being available to discuss your solution?
> I really doubt that this is true for large, legacy code bases, where one is only familiar with a small part of the system.
Reviewers should already be knowledgeable about the part being modified. If no, the review is just for checking for antipatterns in the code, or badly written tests. A bit useful, but can be unnecessary in high trust (or keen on accountability) workplaces.
It is not that I expect it. But instead, it is just about being realistic about how real world projects differ in workflows and conventions. If what you describe is not available, then the next best thing is to make the reviewer aware of the context and solution by means of small commits with sensible descriptions.
Nothing more comfortable than having to use git commits and branching just for telling the agent which lines it messed up instead of simply not writing the garbage in the first place.
Erlang the runtime sure. But Emacs is an application with these properties. There is no editor like Emacs for Erlang (some small clones I am sure) and no other user application utilizing this feature.
Smalltalk is a development environment and an applications platform. The development tools are as extensible and user customizable as Emacs. And like Erlang it is also a runtime you can package software for. Any GUI or server software. For Emacs you can probably do the same, but I’m not convince many users would find the GUI familiar.
reply