1

For debugging purposes it would be helpful to me to reset my repository to the state before a pull (I have no backup), especially, I want to get rid of all the fetched new file contents. Resetting the local and remote branch refs, IMHO would not be sufficient, because the fetched new file contents still would be available in the local repository.

Thomas S.
  • 4,202
  • 2
  • 24
  • 56
  • No exact duplicate, because I also want to get rid of the fetched objects, so a new pull will fetch them again. – Thomas S. Jun 18 '13 at 17:48
  • @ThomasSinger, it's hard to do because in a normal repository a reflog is typically enabled, so you'd have not only to revert every affected branch (remote-tracking and local) but also to expunge the reflog and then do an aggressive run of `git gc`. – kostix Jun 19 '13 at 14:52
  • I agree with kostix, that it probably can't be done with a low effort because of the reflog-files. When you are debugging, why don't you make a backup of the repository before? – mstrap Jun 19 '13 at 15:03

1 Answers1

1

you could either do a git reset --hard HEAD to get back to your previous state. But if that's something you tend to do regularly, and don't want to pay the risk of loosing files you forgot to commit, you'd want to make it as a workflow.

You can keep all those file in your index and stash them on pull, and then git checkout origin/master to get your repository in a sane state. Instead of the stash you may even use branches that you merge/unmerge from your working branch.

There are also tools that help handle files as "patches" for local workspace that will never get in the synchronized index...

zmo
  • 22,917
  • 4
  • 48
  • 82