Re: [PATCH v3 1/6] run-command: add pipe_output_fn to run_processes_parallel_opts

From: Junio C Hamano <gitster@pobox.com>
Date: Oct 24, 2022, 19:04 UTC
Message-ID: <xmqqilk9rqkb.fsf@gitster.g>
In-Reply-To: <CAFySSZABaWSKw_OxyPEU=C_iLOmPa=pPahWaeta=JaAf2q_GEg@mail.gmail.com>

Calvin Wan <calvinwan@google.com> writes:

Show 17 quoted lines

>> In my review of one of the previous rounds, I asked which part of
>> this functionality fits the name "pipe", and I do not think I got a
>> satisfactory answer.  And after re-reading the patch in this round,
>> with the in-header comments, it still is not clear to me.
>>
>> It looks more like sending the duplicate of the normal output to a
>> side channel, somewhat like the "tee" utility, but I am not sure if
>> that is the intended way to be used.
>>
>
> In this case, I was hoping "pipe" would refer to the redirection of
> output from the child processes to a separate custom function, but
> I can see that duplication != redirection. Maybe something like
> "parse_child_output" or "parse_output" would make sense, however,
> I didn't want to imply with that name that the only functionality is to
> parse output. Besides that, I don't really have any other ideas of
> what I can name it...

Yeah, parsing is not to the point. Sending a copy of output to elsewhere is, so redirect is a better word than parse. And piping is not the only form of redirection, either. If duplication is really the point, then either giving it a name with a word that signals "duplication" would make more sense. "send_copy_fn"? I am not good at naming.

As a name that is not end-user facing, it is tempting to assume that the readers have basic knowledge of Unix concepts and call it "tee_fn", but it would be way too cryptic to uninitiated, so I would not recommend it.

Hmm...