On 12/11/2023 23:09, Junio C Hamano wrote: > Elijah Newren <newren@xxxxxxxxx> writes: > >>> Could I suggest that we are missing a piece of terminology, to wit, >>> BLOBSAME. It's a compatriot to TREESAME, as used in `git log` for >>> history simplification (based on a tree's pathspec, most commonly a >>> commit's top level path). >> >> We could add it, but I'm not sure how it helps. We already had 'exact >> rename' which seems to fit the bill as well, and 'blob' is something >> someone new to Git is unlikely to know. > > Also, as Philip said, TREESAME is a concept foreign to rename > detection codepath. It is a property of a commit (not a tree) That (property of a commit?) wasn't really obvious to me. I'd always thought of it as a comparison between two trees, commonly those associated with two commits. Though it could also be thought of as the operation "TREESAME to" that binds in the second tree. and > tells us if it has the same tree object as its relevant parents (in > which case it can be simplified away if it is a merge). I do not > mind rename codepath using a jargon (or two) to express "in trees A > and B, this subtree of A records the same tree object as a subtree > of B at a different path (i.e., the contents of these two subtrees > at different paths are the same)" but the word used to express that > should not be TREESAME to avoid confusion. Maybe it's that the explanation of TREESAME in rev-list-options.txt#L419-L436 [1] has a similar set of confusions about how subtrees are considered and the path v filename confusions. And the other word to > express "this path in tree A records a blob object that is identical > to this other path in tree B" should not be BLOBSAME, as the word > strongly hints it is somehow related to TREESAME. Yep. Naming is hard. > > Thanks. > > Philip [1] https://github.com/git/git/blob/master/Documentation/rev-list-options.txt#L419-L436
