Thank you very much for the links. Actually I've read a few pages of the 
book recently…
And I think I understand the part about blobs, trees, commits… But what I 
don't understand is… if I stage a file, edit it, and stage it again, the 
blob created during the first staging will be purged if I run git purge. 
That happens because no commit was made between the two “adds”/staging. 
Nothing refers to the first one (any more).
I also get that if a commit is amended, we are not supposed to use the 
amended one… or reference it, as the intention of amending is replacing it… 
pretend the replaced commit never happened. 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.

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.

On Friday, 28 September 2012 09:16:04 UTC+1, Konstantin Khomoutov wrote:
> On Thu, Sep 27, 2012 at 05:28:23AM -0700, Thiago Rossi wrote: 
> [...] 
> > Not sure what dangling means. I mean, how it differs from orphans/not 
> being 
> > referenced… 
> > 
> > In my current repository, b95cad5 has been replaced by b219846. Both 
> have 
> > the same parent. But b95cad5 became “invisible” in most interfaces, 
> > including git log, gitk and GitX. 
> This commit should be reachable from the "reflog" of your repository as 
> amending the (tip) commit moved the HEAD in a non-linear way, so this 
> has been recorded to the reflog.  Read the `git reflog` manual for more 
> info. 
> In general, you should just absorb the fact that reaching for the commit 
> replaced by `git commit --amend` is an *unusual* case, and providing for 
> a way to routinely expose it in various parts of Git's user interface is 
> odd.  I mean, when you do `git commit --amend`, provided you read and 
> understood its manual page, you expect that command to completely 
> replace the commit you're amending, as if the original commit just did 
> not exist in the first place.  The fact the original commit is 
> still there by the time `git commit --amend` completed is just an 
> implementation detail of the Git storage backend which uses garbage 
> collection.  The reflog I mentioned above, while not being a recent 
> addition, have not always been there (and it's usually disabled in bare 
> repositories). 
> I understand you might have complications understanding why amending a 
> commit works like it works (that is, why the commit changes, I mean, 
> it's SHA-1 changes).  This is because the commit object consists of 
> metadata and a reference to a tree object, representing the state of 
> files associated with that commit.  The metadata, among other things, 
> records the date and time the commit was made, and the commit message. 
> Observe, that even if you did not change anything in the commit while 
> amending it (I bother to check if Git compares the new commit message 
> with the original one), the commit date/time changes and hence changes 
> the commit object and hence changes its SHA-1.  Changing the tree 
> referenced by the commit (say, adding a forgotten file) changes that 
> tree's SHA-1 hash which is recorded in the commit object and hence 
> changes the commit object itself. 
> If you like to dabble in such technical subtleties to better understand 
> your tools, I highly recommend to read "Git from the bottom up" [1], 
> and if you do not feel quite confident about those SHA-1 hashes and why 
> commit object reference tree objects and stuff, you could start from 
> "The Git Parable" [2] -- it's probably the simplest introduction to the 
> concepts and is very fun to read. 
> Another aspect is that different people have different tastes and 
> different ideas about how a VCS tool should work, and you might just 
> dislike the (frivolous) ways in which Git treats unpushed history (and 
> pushed, too, as you'll discover sometime).  You then can just try to 
> refrain from using `git commit --amend`.  This won't help if you want to 
> fix the commit message up [*], but if you forgot to add a file or want 
> to remove a file, you might just record another commit doing exactly 
> that.  This is not considered to be a best practice, but you know better 
> what works better for your workflow/approach. 
> [*] For instance, Fossil, while not allowing rewriting history at all, 
>     would allow you to change the commit message, but it does this by 
>         recording a special artifact in the repository, and the original 
>         commit message is preserved for later inspection.  As you can see, 
>         Git's developers have radically different idea about how to treat 
>         the unpublished history. 
> 1. 
> 2. 

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
To post to this group, send email to
To unsubscribe from this group, send email to
For more options, visit this group at

Reply via email to