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.

Reply via email to