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 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.
