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 thiagor...@gmail.com 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 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.
