3

I have a question about git reflog:

at the beginning of my project, when I did a git reflog, I was able to see all the steps up to my original git clone command.

Today, git reflog no longer goes back up to the git clone command.

More precisely, git reflog returns 4143 lines, and the last lines is truncated:

$ git reflog
6146d34 HEAD@{0}: checkout: moving from feature/cluster to feature/config
[...]
cb14a86 HEAD@{4140}: checkout: moving from master to demo/20170529
b2ef8d6 HEAD@{4141}: checkout: moving from master to demo/20170529
b2ef8d6 
$

Can anyone explain me why?

Is there a way to get the entire reflog?

Thanks a lot,

Julien

Julien REINAULD
  • 599
  • 2
  • 5
  • 18
  • 2
    It doesn't want people to put random greetings at the start of the question. – Tim Biegeleisen Aug 30 '17 at 11:24
  • 2
    With regard to your actual question, it's my understanding (perhaps flawed) that the reflog periodically can be cleaned out. In other words, if you accidentally nuke a bunch of commits, you would find them safe and sound in the reflog, but they might be garbage collected at some later date. This is not a full answer, nor could I find any documentation for this, but you should not rely on the reflog as being a perpetual record of every commit you make. – Tim Biegeleisen Aug 30 '17 at 11:26

2 Answers2

3

As others have noted, reflogs are temporary by design. I would add this:

You can adjust config settings that affect how long reflog entries are kept, but even so you should regard them as temporary since reflogs are strictly local - that is, they don't go to the remote on a push (or come from the remote on fetch/pull) but rather track the history of refs on the local clone only. So if you ever had to replace your local repo, you would lose all of your reflogs regardless of how your configuration is set up.

UPDATE in response to follow-up question in comments: The relevant settings (which are documented here: https://git-scm.com/docs/git-config) are

gc.reflogExpire
gc.<pattern>.reflogExpire
gc.reflogExpireUnreachable
gc.<pattern>.reflogExpireUnreachable
Mark Adelsberger
  • 42,148
  • 4
  • 35
  • 52
2

@TimBiegeleisen has it right, the reflog is emptied periodically. As long as the reflog holds references to otherwise unreachable commits, they will still stick around in your repository. Only when the commit references are pruned from the reflog ('expired'), the commits will be garbage collected and therefore be gone completely. If this would not happen, commits from deleted branches would stay around forever.

Since such 'dangling' commits and other unused references have already been deleted from your repository and no recording of your repositorys' local history is around, you cannot retrospectively get the entire reflog for your repository.

Edit: Found here:

The reflogs stay until expired (which can be done with the git reflog expire command). The default for unreachable commits is 30 days (or the gc.reflogExpireUnreachable config value) or, for reachable commits, 90 days (or the gc.reflogExpire config value).

This gets confirmed here, and as you can see in the examples, you can also set reflogExpire = never to never let reachable reflog entries expire. This can, however, not bring your already pruned reflogs back, but only prevent deletion in the future.

kowsky
  • 12,647
  • 2
  • 28
  • 41