Skip to content

Support diff seeing broken rename chains #331

@JonJagger

Description

@JonJagger

If a diff is across now-was == 1-8 say (quite large) cyber-dojo of course has access all the intermediate diffs, 2,3,4,5,6,7. So when asked for a 1-8 diff, it could use this knowledge of 2,3,4,5,6,7 to give a "better" diff.

There are two distinct cases where intermediate diffs add information that the 1-8 diff cannot recover on its own.

Completely invisible files
A file created at step 3 and deleted at step 5 leaves no trace in the 1-8 diff — it exists in neither snapshot. The intermediate diffs are the only record it ever existed. Whether surfacing this is useful depends on what the viewer is trying to understand, but the 1-8 diff is genuinely blind to it.

Broken rename chains
This is more practically relevant. Suppose hiker.rb is renamed to diamond.rb at step 4, then its content changes substantially by step 8. The 1-8 diff sees hiker.rb (old content) and diamond.rb (very different content). If the similarity falls below --find-renames's threshold, it reports a delete and a create — losing the rename. But the step 3-4 diff unambiguously records the rename before the content diverged.

By chaining intermediate rename detections — following the identity of a file across steps — you could correctly classify the 1-8 result as a rename even when the endpoint content is too dissimilar for the single-diff heuristic to catch it.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type
    No fields configured for issues without a type.

    Projects

    Status

    New ideas

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions