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. http://newartisans.com/2008/04/git-from-the-bottom-up/ > 2. http://tom.preston-werner.com/2009/05/19/the-git-parable.html > > -- 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/-/b0PR0Mnu-VAJ. 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.
