4

Can someone please help me understand what's happening here?

I start with git log --oneline, which spits out:

4df9421 (HEAD, master) moved some aliases around
d3810e4 (origin/master) some terminal color changes
a7182d3 git colors, ignores, etc.
995fe8c added gitconfig, moved some personal stuff out of the public repo
8a100b7 misc unimportant updates
55d2c08 added a fix to "open with", refactored
7ec7d83 Removed some vim colors; added a couple searching aliases
330c7fc Minor updates
44e80a1 Added vim files
48537c6 Fixed some formatting problems
14933a2 Initial Commit

then I do git reset --hard 330c7fc which takes the log back to:

330c7fc (HEAD, master) Minor updates
44e80a1 Added vim files
48537c6 Fixed some formatting problems
14933a2 Initial Commit

So far so good, but (now that I've reset) when I do git log --oneline --all I get:

 d3810e4 (origin/master) some terminal color changes
 a7182d3 git colors, ignores, etc.
 995fe8c added gitconfig, moved some personal stuff out of the public repo
 8a100b7 misc unimportant updates
 55d2c08 added a fix to "open with", refactored
 7ec7d83 Removed some vim colors; added a couple searching aliases
 330c7fc (HEAD, master) Minor updates
 44e80a1 Added vim files
 48537c6 Fixed some formatting problems
 14933a2 Initial Commit

Notice that the most recent entry, "4df9421 moved some aliases around", is missing from this list.

My understanding is that the --all option should display all the commits. Why is the latest missing once I revert to an earlier commit?

Thanks.

Oliver Taylor
  • 98
  • 6

3 Answers3

6

It is missing, because it isn't reference anymore by HEAD or by a branch.
You have reset both (HEAD and master) to another commit, with your git reset --hard.

Only git reflog would show you that recent commit.

git log --all is only for listing commits referenced in refs/ (like tags, heads, ...)

--all

Pretend as if all the refs in refs/ are listed on the command line as <commit>.

VonC
  • 1,262,500
  • 529
  • 4,410
  • 5,250
  • Got it. That makes sense. I guess it's advisable then to always keep one of your branches on the most recent commit, and if you want to revert to something earlier, do it in a branch. – Oliver Taylor Mar 15 '13 at 15:55
  • @OliverTaylor yes: that way, you keep a reference on the old HEAD, which will then be still visible in the `git log --all`. – VonC Mar 15 '13 at 15:56
  • Which brings up the question, is there a way to combine the commits in reflog with the commits in log? Thus creating a sort-of master list of all commits, regardless of their presence in refs/ – Oliver Taylor Mar 15 '13 at 15:57
  • @OliverTaylor this is generally not advisable, in order to avoid all the pollution left by similar commits dereferenced after, for instance, a rebase (where you get 2 sets of identical commits). That being said, have a look to the `--walk-reflogs` option of `git log`. (as in http://stackoverflow.com/a/746790/6309) – VonC Mar 15 '13 at 15:59
2

The --all option does not tell git log to display all commits. It asks for the logs of all refs, basically your branches and tags. The reset command removed that commit from master, the only ref that had included it so that commit is now unreachable.

qqx
  • 18,947
  • 4
  • 64
  • 68
0

You should accept VonC's answer. To complete it :

The "missing commit" was not pushed to the server, or saved in another branch. Your git reset --hard thus deleted it.

Fortunately, git has some sort of magic undo stack : git reflog. Check VonC's link to figure out how to get it back.

Be careful when you use git reset, this command can destroy commits.

As a rule of thumb : before you manipulate your history, make sure you still have some way of getting back to where you were. My local repositories are crippled with backup, orig and wip branches, which I clean up every month or so.

Community
  • 1
  • 1
LeGEC
  • 46,477
  • 5
  • 57
  • 104
  • "deleted it"? Not exactly. It "*dereferenced it*". Unless you do a `git gc --prune=today --aggressive` (or `git gc --prune=now`), it is still listed in the reflog (for the next 90 days, by default). – VonC Mar 15 '13 at 10:35
  • You are of course right. If anything, you wouldn't be able to recover it otherwise. In a "normal git flow" however, it looks like you really have deleted your commit. – LeGEC Mar 15 '13 at 10:37