2

As part of task I have, I need to consolidate components from three places to one place. In other words, move folders (which include many subfolders and files) to one existing folder.

I'm doing it using git mv, but the issue is that, once I'm trying to merge (using git merge) non consolidated branch to consolidated branch, I get many conflicts, most of which are related to files that Git just moved to the wrong place.

Any idea why Git doesn't know how to handle it correctly? (Git version is latest.)

Example:

Before consolidation:

│   └── dir1
│   │   └── python1
│   │   │   └── test1.py
│   └── dir2
│   │   └── python2
│   │   │   └── test2.py
│   └── dir3
│   │   └── python3
│   │   │   └── test3.py

After consolidation:

│   └── dir1
│   └── dir2
│   │   └── python1
│   │   │   └── test1.py
│   │   └── python2
│   │   │   └── test2.py
│   │   └── python3
│   │   │   └── test3.py
│   └── dir3

Before merge (target tree):

│   └── dir1
│   │   └── python1
│   │   │   └── test1.py
│   │   │   └── test4.py

After merge:

│   └── dir1
│   └── dir2
│   │   └── python1
│   │   │   └── test1.py
│   │   └── python2
│   │   │   └── test2.py
│   │   │   └── test4.py
│   │   └── python3
│   │   │   └── test3.py
│   └── dir3

UPDATE

I'm adding one more case which seems not to be supported in the answer:

Source tree after consolidation:

│   └── dir1
│   └── dir2
│   │   └── python1
│   │   │   └── test1.py
│   │   └── python2
│   │   │   └── test2.py
│   │   └── python3
│   │   │   └── test3.py
│   └── dir3

Before merge (target tree):

│   └── dir1
│   │   └── python1
│   │   │   └── test1.py
│   │   │   └── test4.py
|   |   |   └── new_test
│   │   │       └── test5.py

After merge (with the ORT command as present in the answer):

│   └── dir1
│   │   └── python1
|   |   |   └── new_test
│   │   │       └── test5.py
│   └── dir2
│   │   └── python1
│   │   │   └── test1.py
│   │   │   └── test4.py
│   │   └── python2
│   │   │   └── test2.py
│   │   └── python3
│   │   │   └── test3.py
│   └── dir3

as you can see, it detected new file and its new location (test4.py), but not the new folder (with test5.py). I would expect it will move it as well to its new location under python2 as both file (test4.py) and folder (`new_test) had the same parent (python1). I will check it with GIT support team and will update

arielma
  • 1,308
  • 1
  • 11
  • 29
  • 1
    This needs details or clarity, and you should not use `code` formatting for things which are not code. – tripleee Sep 12 '21 at 11:34
  • Tnx for the comment. I edited the question and added example – arielma Sep 12 '21 at 12:00
  • 2
    Unless I’m mistaken or things have changed, Git internals don’t really have a notion of file renaming. `git mv` is merely a convenience, and commands such as `git status` try to detect this case (a file was deleted and another file with about the same contents has been created), but it gets confused when the file was both renamed *and* modified, so you’d do both in separate steps (commits) to keep things clear. I may be wrong though. – Maëlan Sep 12 '21 at 12:07
  • This might not be related but decide for yourself: https://stackoverflow.com/questions/67067686/git-file-level-merge-conflict-caused-by-git-suggesting-the-file-should-perhap In that question I found Git's behavior with regard to files being moved extremely irritating and overly interventionist. – matt Sep 30 '21 at 07:22

1 Answers1

0

Answer is the same as in this thread (I wasn't aware of it when I wrote it): https://stackoverflow.com/a/69114710/11705021

arielma
  • 1,308
  • 1
  • 11
  • 29
  • 1
    Yes, that new merge strategy (ORT) seems a good (recent) replacement to the old recursive strategy. – VonC Sep 19 '21 at 21:02