--- Original Message -----
From: Thiago Rossi
To: [email protected]
Sent: Saturday, September 29, 2012 1:55 AM
Subject: Re: [git-users] “Ghost” commit
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.
Aha, there is the misunderstanding.
First, it isn't the child relation that is listed. Commit A does not know if it
has any, or lots of, children.
Rather, it is Commit B and Commit C that both (second point) know who their
parent was at the point of their commit snapshot.
Third point it's actually a new commit snapshot. What is actually ammended is
the branch tip pointer, to change from pointing to B, to pointing at C.
The commit B is 'left behind' without a home branch to belong to.
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 [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/git-users?hl=en.
No virus found in this message.
Checked by AVG - www.avg.com
Version: 2012.0.2221 / Virus Database: 2441/5297 - Release Date: 09/28/12
--
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 [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/git-users?hl=en.
