> Junio C Hamano <gitster@xxxxxxxxx> writes: > > > To avoid confusion (although readers may not require), even though I > explained "boring mechanical part" first and "refactoring", that was purely > for explanation. > > In practice, I would expect that it would be easier to both do and review if > refactoring is done with the original name. > > A function that will keep its name in the final result (e.g. > start_multi_file_filter()) will call a new and more generic helper function. The > new helper may start using the new name from the get-go (e.g. > subprocess_start()), but the data types it shares with the original part of the > code (e.g. 'struct cmd2process') may still be using the original name. > > And after completing "2 or more" refactoring would be a good place to do > the remaining "boring mechanical rename". IOW, the count above could be > > 2 or more (refactoring) + > 1 (boring mechanical part) + > 1 (final movement) > > and I didn't mean to say that you need to rename first. What we want is "if > you need to have a single large patch that cannot be split, see if you can > make it purely mechanical.", as a single large patch that is _not_ mechanical > conversion is the worst kind of patch for reviewers. Thanks, I think I better understand what you are looking for in a patch series. In short, any non trivial refactoring should take place within the same file using 1 or more patches to keep each patch as simple as possible. Any large or cross file refactoring should be made as boring/mechanical as possible. This is to make it easier to see any complex changes within a single format patch section and avoid having to look between two file patches to ensure the refactoring didn't unintentionally change behavior. I'll throw out my current refactoring and do it again attempting to follow these guidelines as soon as I can find the time ($DAYJOB tends to take priority over my open source work).