Re: [PATCH 3/7] diffcore-rename: rename num_create to num_targets

>
> "Elijah Newren via GitGitGadget" <gitgitgadget@gmail.com> writes:
>
> > From: Elijah Newren <newren@gmail.com>
> >
> > Files added since the base commit serve as targets for rename detection.
> > While it is true that added files can be thought of as being "created"
> > when they are added IF they have no pairing file that they were renamed
> > from, and it is true we start out not knowing what the pairings are, it
> > seems a little odd to think in terms of "file creation" when we are
> > looking for "file renames".  Rename the variable to avoid this minor
> > point of confusion.
>
> This is probably subjective.
>
> I've always viewed the rename detection as first collecting a set of
> deleted paths and a set of created paths, and then trying to find a
> good mapping from the former into the latter, so I find num_create a
> lot more intuitive than num_targets.
>
> But the remaining elements in the latter set are counted in the
> counter "rename_dst_nr", so we clearly are OK to call the elements
> of the latter set "the destination" (of a rename), which contrasts
> very well with "the source" (of a rename), which is how the deleted
> paths are counted with rename_src_nr.
>
> When doing -C and -C -C, the "source" set has not just deleted but
> also the preimage of the modified paths, so "source" is a more
> appropriate name than "delete".  From that point of view,
> "destination" is a more appropriate name for "create" because it
> contrasts well with "source".
>
> You silently renamed num_create to num_targets in 1/7 without
> justification while adding num_sources.  Perhaps we should go back
> to that step and use num_destinations to match?  The result would be
> using words <dst, src> that pair with each other much better than
> introducing "target" to an existing mix of <create==dst, src> to
> make it <target==dst, src>.