Thank you guys. I was aware only the child knows about the parent, but as 
gitk shows the child. I know in terms of implementation it's only the child 
who knows about its parent. Like the time, there's only the number of 
seconds since 01/01/1970 but we can say day, month, year.

I have just run the suggested command but with a “-unreachable”: git reflog 
expire --all --expire-unreachable=now
Next time I run git prune -n -v it showed me the commit, the tree and the 
blob. What I wanted! :)

I'm not yet sure what would be the difference between git reflog expire 
--all --expire-unreachable=now and git reflog expire 
--expire-unreachable=now but that helped a lot already.

Thank you guys!

On Saturday, 29 September 2012 15:57:28 UTC+1, Konstantin Khomoutov wrote:
> On Fri, 28 Sep 2012 17:55:41 -0700 (PDT) 
> Thiago Rossi < <javascript:>> wrote: 
> [...] 
> > What I don't understand (or see the reasons) is why the blob for the 
> > amended commit is not “purge-able”… If it's not listed there, I guess 
> > something is referencing to it, and I wonder what, as it seems only 
> > reflog is capable of show it. 
> It's not purge-able precisely because the reflog is enabled in your 
> repository (this is the default), and the reflog records all non-linear 
> movenent of branches.  You could also use the terms "drastic" or 
> "catastrophic" for such movements -- they are those which would 
> otherwise leave the previous commit a branch pointed at before it 
> moved truly dangling.  When you run `git commit --amend`, you throw 
> away the tip commit of your current branch and replace it with another 
> one -- this is such a drastic movement of a branch.  The reflog keeps a 
> reference to the previous state of a branch, precisely for the reasons 
> of easy recovery, if needed. By default, the reflog keeps its history 
> for 30 days or so. 
> Again, please note that you should not really care about whether Git 
> killed that replaced commit or not, or if that loose commit and the 
> objects it references are dangling and need to be garbage-collected -- 
> this stuff is only to be considered when for some reason you're facing a 
> serious disk space/process memory issue, otherwise a Git repository is 
> self-maintaining: Git will periodically garbage-collect and pack it so 
> there's nothing to worry about.  A disk space/memory issue may occur if, 
> say, someone commits a huge file by mistake, you undo this action and 
> do really want that file to go away *physically* to not waste disk space 
> (which might be an issue when the repo is hosted on a VDS for instance). 
> But this is a special case, and you can combat it with a special tools 
> like `git reflog expire --all --expire=now` followed by 
> `git gc --prune=now` or something like this. 
> > If I have 
> > A <--- B and amend B, now I have 
> > A <--- C, and B, as far as I know, is no longer listed as a child of 
> > A and doesn't have A as a parent. reflog shows B, but who is using B? 
> > I am able to checkout B if I know its SHA1 code, and I think it would 
> > be a bad idea… I don't know why B can't be purged then. 
> The reflog is "using" B by referencing it. 
> The rest is as Philip already pointed out: the parent/child relations 
> are reversed in a DVCS system -- it's children who reference their 
> parents, not the other way around.  This will become logical once you 
> recall that commits in a DVCS systems are immutable, so once the commit 
> has been recorded you can't retrofit a reference to a child in it. 
> Hence the implemented scheme is way more flexible: you can add/remove 
> any number of children any time without touching any commits at all. 

You received this message because you are subscribed to the Google Groups "Git 
for human beings" group.
To view this discussion on the web visit
To post to this group, send email to
To unsubscribe from this group, send email to
For more options, visit this group at

Reply via email to