0

I think I have a very serious problem.

The short of it: Github Desktop very weirdly only committed a single file in a slew of files that had been changed. I then did a sync. So, remote Github confirms that I've only committed a single file.

Now, for one reason or another, all of my files are a reflection of a version prior to the last commit.

Amended illustration

I'm really, really worried. I attempted to fix this myself, with a series of git reflog and git reset HEAD^ (stupid, I know), but I haven't seen any results. I cannot seem to get back all that I had worked on just before my last commit. Is there any one who can help me?

Modermo
  • 1,852
  • 2
  • 25
  • 46

2 Answers2

0

HEAD^ is the first parent of your current commit. So if you use it, you just go further back in the history. You probably want to use the syntax you see in the reflog like HEAD@{n} which means the n-th commit HEAD point to before now. Or you can simply use the SHA of the "Commit Today".

Vampire
  • 35,631
  • 4
  • 76
  • 102
  • The thing is, I'm trying to UNDO the commit and get all my work BEFORE that commit. If I go further back in history, the commit before my last erroneous one is really far back in time (my fault for not doing more regular commits). – Modermo Apr 20 '17 at 09:16
  • Hm, then I guess I misunderstood your question. Could you maybe rephrase it to make it clearer? What do you want to undo? What is the desired result of the operation? ...? – Vampire Apr 20 '17 at 09:23
  • I've just edited the illustration. Basically, I want to get the work I've completed since my last 'good' commit one month ago. Everytime I undo the erroneous commit from today, it just reverts to my last commit i.e. I want to go back to my working directory. – Modermo Apr 20 '17 at 09:39
  • If you do `git reset HEAD~` (while you are at the erroneous commit), then your working tree is untouched and you effectively undid the erroneous commit and also the addition of stuff to the index. A `--soft' reset would just have undid the commit, leaving index and worktree untouched, a `--hard` commit would also reset your worktree to the previous commit. If you did throw away uncommitted changes in the worktree, e. g. by a `reset --hard`, there is no way to get them back. Git does not know anything about files / changes in your worktree as long as you don't add them to the index. – Vampire Apr 20 '17 at 10:07
0

As it turns out, Github Desktop actually stashed the changes. I refer to this answer that gave me the fix I needed. Apparently it has happened to a bunch of other people before.

Community
  • 1
  • 1
Modermo
  • 1,852
  • 2
  • 25
  • 46