On Wed, Jul 31, 2024 at 04:49:54PM +0300, Alexander Korotkov wrote: > On Mon, Jul 29, 2024 at 7:20 PM Robert Haas <robertmh...@gmail.com> wrote: >> I support that idea in general but felt it was overkill in this case: >> it's new code, and there was only one existing caller of the function >> that got refactored, and I'm not a huge fan of cluttering the git >> history with a bunch of tiny little refactoring commits to fix a >> single bug. I might have changed it if I'd seen this note before >> committing, though. > > I understand your point. I'm also not huge fan of a flood of small > commits. Nevertheless, I find splitting refactoring from other > changes generally useful. That could be a single commit of many small > refactorings, not many small commits. The point for me is easier > review: you can expect refactoring commit to contain "isomorphic" > changes, while other commits implementing material logic changes.
For review, it also tends to matter a lot to me, especially if the same areas of code are changed across multiple commits. That's more annoying for authors as the splits are annoying to maintain. For a single caller introduced, what Robert has done is fine IMO. > But that might be a committer preference though. I tend to prefer refactorings if it comes to a cleaner git history, still that's always case-by-case, and all of us have our own habits. -- Michael
signature.asc
Description: PGP signature
