Re: Git Rename Detection Bug

From: Philip Oakley <philipoakley@iee.email>
Date: Nov 11, 2023, 11:08 UTC
Message-ID: <9baca4af-a570-4b7a-a1ee-de91b809e79c@iee.email>
In-Reply-To: <CABPp-BHEX+SyophEfgRqDbNdrAS3=bptt_cKzHLBSutnBAxexw@mail.gmail.com>

Hi all,

On 11/11/2023 05:46, Elijah Newren wrote:

> The fact that you were trying to "undo" renames and "redo the correct
> ones" suggested there's something you still didn't understand about
> rename detection, though.

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

File rename, at it's most basic, is when the blob associated with that changed path is identical, i.e. BLOBSAME. There is no need to 'record' the action of renaming, moving or whatever, the content sameness is right there, in plain sight, as an identical blob name. After that (files with slight variations) it is a load of heuristics, but starting with BLOBSAME we see how easy the basic rename detection is, and why renames (and de-dup) don't need recording.

The heuristics of 'rename with small change' is trickier, but for a basic understanding, starting at BLOBSAME (and TREESAME for directory renames) should make it easier to grasp the concepts.

--

Philip