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 
For more options, visit this group at 

Reply via email to