"Elijah Newren via GitGitGadget" <gitgitgadget@xxxxxxxxx> writes: > From: Elijah Newren <newren@xxxxxxxxx> > > 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>.
