0

I made a rookie error and reverted the same commit twice, which in the "git alternate universe" resulted in all of my local files on my test server being deleted.

Therefore on production server I ran a git commit on that added everything on the production server to a git commit.

Following this I used git fetch --all, which downloaded everything my local test server.

Problem:
I don't seem to be able to checkout the files or otherwise restore the files to their places on the test server.

Attempts
git checkout <remote>/master -f <-- doesn't work
git reset --hard <remote>/master <-- doesn't work

I have read this post, How do I force "git pull" to overwrite local files?

While I am sure the commit that I did on the remote server included all files, when I use git reset --hard <remote>/master I just get a message: HEAD is now at 8f894be all remote files, but no files in correct locations on local test server....

Any tips?

B-zaro
  • 205
  • 1
  • 14
  • _"reverted the same commit twice"_ - **exactly** what commands did you run? – Dai Sep 11 '22 at 06:18
  • @Dai First I ran `git log` to get the shasum of the bad commit, before bed I ran `git revert shasum`, then in the morning (before coffee) I ran `git revert same shasum`, bang... all local files gone – B-zaro Sep 11 '22 at 06:24
  • 1
    As you didn't run `git reset` (I hope?) it's possible your files are still around somewhere... so I recommend you install a _good_ git GUI (such as GitKraken or SourceTree) as that will help you understand what's inside your repo. (it's a shame that `git`'s in-box GUI/GTK tooling is a bit naff...) – Dai Sep 11 '22 at 06:25
  • @Dai I will install GitKraken, but for time being... I just want to get my files back – B-zaro Sep 11 '22 at 06:28
  • @B-zaro is the remote has your original files? it looks like you add more salt to your wound on each step.. try to make a new clone and see if they have what you wanted. also, git GUI as Dai mentioned surely do help avoiding mistakes such as this. – Bagus Tesa Sep 11 '22 at 06:42
  • Can't you just do `git clone` to a new empty directory for now? – Dai Sep 11 '22 at 06:42
  • figured it out... my remote git commit was bad... the files were in a separate directory from the repo... so I had to add a work-tree directive pointing to the actual files, then do the commit... after that the above checkout command worked... files are back – B-zaro Sep 11 '22 at 07:11
  • 2
    The premise of this question appears to be flawed. Reverting the same commit a second time should have no effect, and certainly wouldn't unexpectedly delete any files. – TTT Sep 11 '22 at 15:11
  • 1
    I don't believe GUIs make things better in general. They often make things *worse*. A good GUI is, at best, effective at reminding you about common options that might be useful at this point and/or showing you results. Note that tweaking the *working tree location* is outside the purview of most GUIs, so that they won't be able to help at all for these cases. – torek Sep 11 '22 at 19:38

1 Answers1

0

another rookie error..

The remote server's repo was collecting/holding files from a different working directory. Therefore, I had to use:

git --work-tree=/home/username/public_html/ add ../../* and git --work-tree=/home/username/public_html/ commit -m "don't a ninny" in order to properly commit the remote files before fetching them and checking them out locally with:

git fetch <remote> master

git checkout <remote> master -f

yes, its time to install a git gui...

B-zaro
  • 205
  • 1
  • 14