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 <[email protected] <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 https://groups.google.com/d/msg/git-users/-/OvWkFOYGqMUJ. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/git-users?hl=en.
