Re: Git Rename Detection Bug
Junio C Hamano
Elijah Newren
Jeremy Pridmore
Paul Baumgartner
Philip Oakley
See Also
Prev Ref 1 Ref 2 Ref 3 Ref 4
2023-11-15 15:35:33 UTC
On 12/11/2023 23:09, Junio C Hamano wrote:
> Elijah Newren <> 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.

> 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.