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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



> -----Original Message-----
> From: Junio C Hamano [mailto:gitster@xxxxxxxxx]
> Sent: Thursday, March 23, 2017 2:17 AM
> To: Ben Peart <peartben@xxxxxxxxx>
> Cc: git@xxxxxxxxxxxxxxx; Ben Peart <Ben.Peart@xxxxxxxxxxxxx>;
> christian.couder@xxxxxxxxx; larsxschneider@xxxxxxxxx
> Subject: Re: [PATCH v1 2/3] sub-process: refactor the filter process code into
> a reusable module
> 
> Ben Peart <peartben@xxxxxxxxx> writes:
> 
> > This code is refactored from:
> >
> > 	Commit edcc85814c ("convert: add filter.<driver>.process option",
> 2016-10-16)
> > 	keeps the external process running and processes all commands
> 
> I am afraid that this organization of the patch series is making it harder than
> necessary to review, by duplicating the same code first _WITH_ renaming of
> symbols, etc., in this step and then updaing the original callers while
> removing the now-stale original callee implementation in a separate next
> step.
> 
> Would it perhaps make it clearer to understand what is going on if you
> instead started to update the code in convert.c in place to make it more
> suitable fro reuse as the patch title advertises, and then move the resulting
> cleaned-up code to a separate file, I wonder.

I'm not entirely sure what you're asking for here but I think the
challenge may be that by splitting the refactoring into two separate
commits, it's hard to see the before and after when looking at the
commit in isolation.  By splitting them, it's more "a bunch of new code"
followed by "using new code" than it is a refactoring of existing code.

How about I squash the last two patches together so that its more
apparent that it's just a refactoring of existing code with the before
and after in a single patch?




[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]