0

I read this answer and (wrongly I guess) thought that it meant git reset could also be used to casually browse through the repository's historical states.

So I went and git reset {some old sha1} to see what the files and state of the repository looked like back then.

Then I wanted to get back so I did git reset HEAD.

But now I can see my repository is not as it was before, and I have no idea what kind of state it's in right now.

How do I return to before all of this happened?

theonlygusti
  • 11,032
  • 11
  • 64
  • 119
  • The first `git reset` adjusted your current branch name so that it points to the old commit, rather than the current commit. The second `git reset` adjusted the name again, but this time to keep the current value. You therefore need to reset to `HEAD@{2}`: the value from two steps ago. The linked duplicate is correct; it's just that the accepted answer starts with the case where you did only *one* `git reset`. – torek Jul 18 '20 at 23:28
  • Meanwhile, to check out some old commit, consider using either `git checkout ` or `git switch --detach ` (`git switch` is new in Git 2.23, so if your Git is older you need to use the older command spelling, which still works in the newer Git versions). These put you into *detached HEAD* mode, which is usually what you want for this kind of browsing. – torek Jul 18 '20 at 23:29
  • Yeah I am used to `git checkout` to browse history, but I saw that answer and thought I'd try it. `git reset HEAD@{2}` didn't help... how do I get the most recent sha1 – theonlygusti Jul 19 '20 at 11:29
  • Use `git reflog` or `git reflog ` (the first one shows the HEAD reflog, the second shows the reflog for the specified branch name) to view a short listing of commits to which HEAD or the branch name *used* to point. From that list, pick out the correct commit (somehow—this is the hard part) and then use `git reset` with either that `@{number}` or the raw hash ID. The @{n} syntax is relative so it keeps moving; the hash IDs stay fixed, but are hard to type correctly (use mouse to cut and paste). – torek Jul 19 '20 at 15:44
  • The key to understanding this is to realize that for Git, the *names* (`master`, `develop`, etc) don't really matter: it's the *hash IDs* that matter. The hash IDs never change; the names map to the *latest* commit hash ID. (There's a lot more to it, but this is the first key: Git is really about the hash IDs. The names have several purposes but the #1 purpose is "branch name" = "*last* commit". The `git reset` command changes the stored hash ID and hence changes which commit is "last".) – torek Jul 19 '20 at 15:48

0 Answers0