On Mon, Oct 24, 2022 at 12:04 PM Junio C Hamano <gitster@xxxxxxxxx> wrote: > > Calvin Wan <calvinwan@xxxxxxxxxx> writes: > > >> 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... Throwing some more ideas out there: split_duplicate_fn duplicate_output_fn dup_output_fn As you mention, it's not end-user facing so we should pick a name that's close enough (and any confusion can always be resolved by comments)
