On Fri, 28 Sep 2012 17:55:41 -0700 (PDT) Thiago Rossi <thiagorossi...@gmail.com> 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 post to this group, send email to git-users@googlegroups.com. To unsubscribe from this group, send email to git-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/git-users?hl=en.
