On Tue, Feb 20, 2024 at 12:02 PM John Gabo <charleforalia@xxxxxxxxx> wrote: > > Hello, > I think I found a bug in git, where a change get attributed to the > wrong file when doing a rebasing. > > # Short summary > Assume `master_branch` > ``` > . > └── parent_folder > ├── project_a > │ └── file.txt > └── project_b > └── file.txt # the 2 file.txt have the same content on master > ``` > Assume `feature_branch` from master > ``` > . > └── parent_folder > ├── project_a > │ └── file.txt > └── project_b > └── file.txt # this file got modified with a feature > ``` > Assume `refactor_branch` from master > ``` > . > └── refactored_parent_folder # got renamed > ├── project_a > │ └── file.txt > └── project_b > └── file.txt > ``` > then rebase `feature_branch` on `refactor_branch`, > > ``` > . > └── refactored_parent_folder > ├── project_a > │ └── file.txt # the feature got moved here ! > └── project_b > └── file.txt # instead of here, where it should be ! > ``` You may want to read through the Support section of https://git.github.io/rev_news/2024/01/31/edition-107/. You are dealing with inexact renames rather than exact, but it's still the same basic issue: git is detecting renames based on file similarity and you have multiple equally valid targets for it to choose, so it simply picks one. As such, it might be considered a limitation of rename detection that you can't manually enforce which files are paired, but it's not what we'd classify as a bug since it did correctly pick one of the files with the most similar contents.
