Re: [PATCH v1 2/3] sub-process: refactor the filter process code into a reusable module

From: Junio C Hamano <gitster@pobox.com>
Date: Mar 24, 2017, 17:15 UTC
Message-ID: <xmqqd1d68ukr.fsf@gitster.mtv.corp.google.com>
In-Reply-To: <xmqqpoh68xld.fsf@gitster.mtv.corp.google.com>

Junio C Hamano <gitster@pobox.com> writes:

Show 10 quoted lines

> ...
> And for something of sub-process.[ch]'s size, I suspect that it
> would have more than 1 such logical unit to be independently
> refactored, so in total, I would suspect the series would become
>
>     1 (boring mechanical part) +
>     2 or more (refactoring) +
>     1 (final movement)
>
> i.e. 4 or more patches?

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.