1

I am trying to figure out how a file somehow disappeared from a project so I ran this command:

git log -- .eslintrc.json

which returned nothing. So I figured maybe I didn't commit it when I thought I did.

I then ran this command to confirm:

git diff commit_where_i_added_it^ commit_where_i_added_it

This returned:

diff --git a/.eslintrc.json b/.eslintrc.json
new file mode 100644
index 0000000..92a588d
--- /dev/null
+++ b/.eslintrc.json
@@ -0,0 +1,18 @@
+{
+    "env": {
+        "browser": true,
+        "es6": true,
+        "node": true
+    },
+    "extends": "google",
+    "globals": {
+        "Atomics": "readonly",
+        "SharedArrayBuffer": "readonly"
+    },
+    "parserOptions": {
+        "ecmaVersion": 2018,
+        "sourceType": "module"
+    },
+    "rules": {
+    }
+}
.
.
.

So clearly the file exists in git. My question is this then: How can git log -- .eslintrc.json not return anything when the file exists in a certain commit? Am I misunderstanding the command? I have used it on other files and it works as expected.

P.S all of the above is happening on the same branch. The commit where I added the file exists on the branch I am running this command

KNejad
  • 2,376
  • 2
  • 14
  • 26
  • 1
    How about `git log --follow -- .eslintrc.json`? – ElpieKay Jun 13 '19 at 13:44
  • Oh that shows the commit where I added it. But nothing after that. So it's not showing where it was removed. I still don't get why that would have happened though? I didn't rename the file. Am I mistaken in thinking that the correct behaviour of this command is to at least show when the file was created? – KNejad Jun 13 '19 at 13:49
  • 1
    See this answer, https://stackoverflow.com/a/56556222/6330106. It might be the same problem. – ElpieKay Jun 13 '19 at 13:53
  • Okay with a git bisect command I managed to find out where it was removed. Except when I list the changed files in that commit it doesn't show .eslintrc.json... I really think something in the git tree has broken here. Either that or I am misunderstanding git now... – KNejad Jun 13 '19 at 13:56
  • Okay that's a much larger and more complicated answer than I was expecting. I will book mark that for now and read through it again in more detail once I get the chance... But after the first read of that question I still expect at least the first commit to appear yet that doesn't with the standard git log. Okay, I'll read through it a bit more and see if I can make sense of it then get back to you. Thanks :) – KNejad Jun 13 '19 at 14:07
  • So will I. The 2 questions make me feel I don't understand Git any more. – ElpieKay Jun 13 '19 at 14:35
  • @ElpieKay The part I left out of the TL;DR section (it's in at the bottom of the long section) is that history simplification does exactly the *wrong* thing when a change you made was wiped out by a bogus merge, because the simplifier thinks that the merge that destroyed your change was *intended* to be that way and that you want it to ignore both that merge *and* all the history where you made the change originally. (But that's an oversimplification—it's really all in that TREESAME stuff. Which I think doesn't work well at all at octopus merges.) – torek Jun 13 '19 at 15:25
  • @torek You're a lifesaver. It'll take some time before I can digest your answer. – ElpieKay Jun 13 '19 at 16:09

0 Answers0