2

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?

arielma
  • 1,308
  • 1
  • 11
  • 29
  • A slight quirk of git's design is that it doesn't actually track copies or renames in any permanent way. Instead, various history commands have options to *reconstruct* renames when they compare commits. So, it matters what command you're using to try to see the history of test4.py – IMSoP Sep 12 '21 at 18:17
  • `git blame` / `gitk` / `git log` , and also tried via intelji GUI, but nothing show the history – arielma Sep 12 '21 at 18:31
  • The way to think of this is: Git doesn't *have* file history. Git has commits, and the commits are the history. `git log` shows the commits as found by the fact that they are the history; `git log -- path` selects a *subset* of commit-history to walk, and then shows an *even smaller subset* of that subset; `git log --follow -- path` attempts to detect file renames and modifies the way that `git log -- path` works by changing *which* path it's using to do the subset-selecting, as it goes. – torek Sep 12 '21 at 20:01
  • This all works fairly well for most cases, but in complicated rename-and-rework cases, it can fail pretty hard. You seem to have one of those cases. – torek Sep 12 '21 at 20:01
  • In the future, try to avoid moving/renaming a file *and* changing it in the same commit. If you can do one, and not the other, git is almost guaranteed to be able to follow the history of the file across renames and moves. – Lasse V. Karlsen Sep 12 '21 at 21:09
  • I'm not changing any file. What I present was consolidation, and then `git merge` bring new file from feature branch which wasn't exists on master, and since it goes to new path (due to consolidation), the commit history got deleted. – arielma Sep 12 '21 at 21:13
  • This is just a repeat of your https://stackoverflow.com/questions/69150777/git-mv-doesnt-work-as-expected-wrong-files-location which was closed. Please don't do that. You should edit the previous question to make it better, not litter SO with multiple versions of the same question. – matt Sep 12 '21 at 21:18
  • That question was more about wrong path location. Here I'm focusing only on the file commit history which is missing – arielma Sep 12 '21 at 21:37

1 Answers1

3

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.

jthill
  • 55,082
  • 5
  • 77
  • 137
  • So it means there is no way to get the file history for `dir2/python1/test4.py`? – arielma Sep 12 '21 at 19:07
  • I misread your question, I stopped at "non existing test4.py" and didn't see it tucked in there under dir2. If the merge didn't also change it beyond recognition `gitk --follow -- dir2/python1/test4.py` and so on will do just fine. – jthill Sep 12 '21 at 19:40
  • I clarified the question. anyway it doesn't work, I don't see the history using this command on `dir2/python1/test4.py` – arielma Sep 12 '21 at 19:50
  • If it's been moved and substantially changed you might have to broaden the search with something like `-M50`, see the `git log` docs, `gitk` takes all of log's selection arguments. – jthill Sep 12 '21 at 19:50
  • Well,I'm doing my command testing on the git history with git-legacy-stash.sh and it works perfectly, so there's something particular about your history that's tripping up the rename-tracking mechanism. Is it a public repo? – jthill Sep 12 '21 at 21:44