I have the below scenario:
main branch before consolidation:
│ └── dir1
│ │ └── python1
│ │ │ └── test1.py
│ └── dir2
│ │ └── python2
│ │ │ └── test2.py
│ └── dir3
│ │ └── python3
│ │ │ └── test3.py
main branch after consolidation:
│ └── dir1
│ └── dir2
│ │ └── python1
│ │ │ └── test1.py
│ │ └── python2
│ │ │ └── test2.py
│ │ └── python3
│ │ │ └── test3.py
│ └── dir3
feature branch before merge (test4.py history has 10 commits in history):
│ └── dir1
│ │ └── python1
│ │ │ └── test4.py
main branch after merge from feature branch (using git merge -s ort and resolving the conflict on non existing test4.py):
│ └── dir1
│ └── dir2
│ │ └── python1
│ │ │ └── test1.py
│ │ │ └── test4.py
│ │ └── python2
│ │ │ └── test2.py
│ │ └── python3
│ │ │ └── test3.py
│ └── dir3
The problem is that all the history of test4.py got deleted... any idea why it happens and if its avoidable?
If the merge deleted dir1/python1/test4.py from your target tree, then the branch you merged deleted that file. But I see now that it just moved it. If you want to see the history of that file,
gitk --follow -- dir2/python1/test4.py
will show it to you if it hasn't also changed beyond recognition. You can try adding -M50 if it has very substantially changed, and --full-history to inspect ancestry that didn't wind up having any effect on the mainline, just in case you want to see changes that were abandoned or otherwise wound up identical to changes Git's already showing you..
git blame always runs --follow (that's so often what's wanted nobody's taught it any option not to do that yet), but you do have to hunt down a commit that has it.
If a file wasn't just moved but actually deleted, if it doesn't exist now, git log -1 --pretty=%h -- path/to/that/test4.py will find the commit that deleted it, tack a ^ on the end of that one's output and that's the last commit before it got deleted.