3

I've made a mistake and am looking to recover a file that was somehow deleted from my GitHub repository. The file was amarkdown file edited and created in the GitHub interface online, so it hasn't shown up in my local log, and didn't surface after a git fetch or git pull. I've read quite a few other posts here on how to find deleted files, but they haven't fit my case:

For instance with this post: Git: How to search for a deleted file in the project commit history? Running the suggested command:

git log --all -- **/thefile.*

yielded no results (printed nothing at all). I've also run the command for finding all file deletions in the git history:

git log --all --diff-filter=D --summary

and didn't find what I was looking for.

I'm thinking this has to do with the fact that I created and edited the file directly in the GitHub remote repo. It may have never been in my local repo and may have been overwritten somehow with a push. I'm relatively inexperienced with Git, so I'm not sure how to proceed from here. Any suggestions on how to proceed, or am I S.O.L? Is there a sequence of events that could lead to something like this, that I can avoid in the future? Thank you!

Community
  • 1
  • 1
kingb12
  • 76
  • 7
  • 2
    As long as you committed the file at some point, it's probably around. Have you run `git fetch` to make sure you have everything locally? Is your repo public so we can help look? – Kristján May 01 '16 at 23:54

1 Answers1

4

How to find when changes was made to the repository?

Bottom line: you should use git bisect for this task.

In depth explain:

If you wish to search manually throw the log as you did you can use the git log --cc (git v>2.X). It will show you list of changes in each commit

You can of course dump it to file and search the file content or screen.

enter image description here

But what to do if i have too many commit to go over them manually?

This is where git bisect comes to rescue. git bisect search over your repos and based upon an given exit code it can determine which commit started the "problem".

You can use bisect manually or pass it a script to automate the process with a script. (See bisect run below)

The bisect command does a binary search through your commit history to help you identify as quickly as possible which commit introduced an issue.

Let’s say you just pushed out a release of your code to a production environment, you’re getting bug reports about something that wasn’t happening in your development environment, and you can’t imagine why the code is doing that. You go back to your code, and it turns out you can reproduce the issue, but you can’t figure out what is going wrong.

You can bisect the code to find out.
First you run git bisect start to get things going, and then you use git bisect bad to tell the system that the current commit you’re on is broken. Then, you must tell bisect when the last known good state was, using git bisect good [good_commit]...

Bisect run

If you have a script that can tell if the current source code is good or bad, you can bisect by issuing the command:

git bisect run my_script arguments

Note that the script (my_script in the above example) should exit with code 0 if the current source code is good/old, and exit with a code between 1 and 127 (inclusive), except 125, if the current source code is bad/new.

Any other exit code will abort the bisect process.

The special exit code 125 should be used when the current source code cannot be tested. If the script exits with this code, the current revision will be skipped (see git bisect skip above).

125 was chosen as the highest sensible value to use for this purpose, because 126 and 127 are used by POSIX shells to signal specific error status (127 is for command not found, 126 is for command found but not executable—​these details do not matter, as they are normal errors in the script, as far as bisect run is concerned).

Here is a graphical luustartion on it works
http://www.effectiveperlprogramming.com/wp-content/uploads/bisect1.png

enter image description here

Here is a sample code in one of my guthub repos to see how you use it

enter image description here

CodeWizard
  • 128,036
  • 21
  • 144
  • 167
  • Cool answer, hadn't considered using this. My only issue is that I am having trouble labelling 'good' and 'bad' revisions. I'm not finding the file at all in my history, and I am merely looking for any version of it (it wasn't code, it was just a long markdown page I'd written to share with a co-worker on GitHub). My script tests for the existence of this file, but I think in order to have a 'good' commit to pass to bisect, I'd have to be able to find a commit where this file is included. Is there a way around this? Thank you for such an in depth and thoughtful answer! – kingb12 May 02 '16 at 17:30
  • 2
    hey. I made that image, and here I am years later looking for help on the thing I wrote about already. It's even worse when I search for something and find my own answer. :) – brian d foy Nov 11 '20 at 12:33