What's the difference between git reflog and l

Question

The man page says that log shows the commit logs and reflog manages reflog information. What exactly is reflog information and what does it have that the log doesn't? The log seems far more detailed.

Answer 1

Here's the explanation of reflog from the Pro Git book:

One of the things Git does in the background while you’re working away is keep a reflog — a log of where your HEAD and branch references have been for the last few months.

You can see your reflog by using git reflog:

$ git reflog
734713b... HEAD@{0}: commit: fixed refs handling, added gc auto, updated
d921970... HEAD@{1}: merge phedders/rdocs: Merge made by recursive.
1c002dd... HEAD@{2}: commit: added some blame and merge stuff
1c36188... HEAD@{3}: rebase -i (squash): updating HEAD
95df984... HEAD@{4}: commit: # This is a combination of two commits.
1c36188... HEAD@{5}: rebase -i (squash): updating HEAD
7e05da5... HEAD@{6}: rebase -i (pick): updating HEAD

Every time your branch tip is updated for any reason, Git stores that information for you in this temporary history. And you can specify older commits with this data, as well.

The reflog command can also be used to delete entries or expire entries from the reflog that are too old. From the official Linux Kernel Git documentation for reflog:

The subcommand expire is used to prune older reflog entries.

To delete single entries from the reflog, use the subcommand delete and specify the exact entry (e.g. git reflog delete master@{2}).

Answer 2

• git log shows the commit log accessible from the refs (heads, tags, remotes)
• git reflog is a record of all commits that are or were referenced in your repo at any time.

That is why git reflog (a local recording which is pruned after 90 days by default) is used when you do a "destructive" operation (like deleting a branch), in order to get back the SHA1 that was referenced by that branch.
See git config:

gc.reflogexpire
gc.<pattern>.reflogexpire

git reflog expire removes reflog entries older than this time; defaults to 90 days.
With "<pattern>" (e.g. "refs/stash") in the middle the setting applies only to the refs that match the <pattern>.

git reflog is often reference as "your safety net"

In case of trouble, the general advice, when git log doesn't show you what you are looking for, is:

"Keep calm and use git reflog"

Again, reflog is a local recording of your SHA1.
As opposed to git log: if you push your repo to an upstream repo, you will see the same git log, but not necessarily the same git reflog.

Answer 3

I was curious about this as well and just want to elaborate and summarize a bit:

1. git log shows a history of all your commits for the branch you're on. Checkout a different branch and you'll see a different commit history. If you want to see you commit history for all branches, type git log --all.

2. git reflog shows a record of your references as Cupcake said. There is an entry each time a commit or a checkout it done. Try switching back and forth between two branches a few times using git checkout and run git reflog after each checkout. You'll see the top entry being updated each time as a "checkout" entry. You do not see these types of entries in git log.

References: http://www.lornajane.net/posts/2014/git-log-all-branches

Answer 4

Actually, reflog is an alias for

 git log -g --abbrev-commit --pretty=oneline

so the answer should be: it is a specific case.

Answer 5

git log shows the current HEAD and its ancestry. That is, it prints the commit HEAD points to, then its parent, its parent, and so on. It traverses back through the repo's ancestry, by recursively looking up each commit's parent.

(In practice, some commits have more than one parent. To see a more representative log, use a command like git log --oneline --graph --decorate.)

git reflog doesn't traverse HEAD's ancestry at all. The reflog is an ordered list of the commits that HEAD has pointed to: it's undo history for your repo. The reflog isn't part of the repo itself (it's stored separately to the commits themselves) and isn't included in pushes, fetches or clones; it's purely local.

Aside: understanding the reflog means you can't really lose data from your repo once it's been committed. If you accidentally reset to an older commit, or rebase wrongly, or any other operation that visually "removes" commits, you can use the reflog to see where you were before and git reset --hard back to that ref to restore your previous state. Remember, refs imply not just the commit but the entire history behind it.