From: Elijah Newren Date: Thu, 10 Dec 2020 02:25:36 GMT Subject: Re: [PATCH 3/7] diffcore-rename: rename num_create to num_targets Message-ID: In-Reply-To: On Wed, Dec 9, 2020 at 6:20 PM Junio C Hamano wrote: > > "Elijah Newren via GitGitGadget" writes: > > > From: Elijah Newren > > > > 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 that pair with each other much better than > introducing "target" to an existing mix of to > make it . Ooh, I like it. num_destinations it is.