On Wed, Jul 31, 2024 at 04:49:54PM +0300, Alexander Korotkov wrote:
> On Mon, Jul 29, 2024 at 7:20 PM Robert Haas <robertmhaas@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
