Hum, well it might be currently implemented in a way that leaves traces,
but it seems amend is documented to replace the previous commit with the
new one. Future implementations and garbage collection may vary. What's the
purpose of trying to see if traces of this previous commit exist anyway?
Just playing around to reverse-engineer the implementation of amend? Git if
open-source so you could dig into the code too I suppose.

On Thu, Sep 27, 2012 at 9:17 PM, Adam Prescott <a...@aprescott.com> wrote:

> When you amend the second commit replaces the results of the first. It's
>> for the occasion when you commit too early and possibly forget to add some
>> files, or you mess up your commit message.
>
>
> I don't think you're answering on the same level of abstraction as
> Thiago's question. At a high level, the commit has indeed been "replaced",
> but the commits D and E are both separate entities as far as Git is
> concerned, it's just that E's parent has been set to C and D isn't
> reachable from any ref; D is in a dangling state.
>
> Try this:
>
> cd /tmp
> git init foo
> cd foo
> touch foo
> git add foo
> git commit -a -m "Initial commit"
> touch bar
> git add bar
> git commit -a -m "Bar"
> git log --oneline
>
> # output:
> 2e1c949 Bar
> 499724c Initial commit
>
> git commit --amend
> # amend the message to be "Bar (edited)"
>
> git log --oneline
>
> # output:
> 94e441b Bar (edited)
> 499724c Initial commit
>
> Now look at the log starting from the commit that was amended (2e1c949):
>
> git log --oneline 2e1c949
>
> # output:
> 2e1c949 Bar
> 499724c Initial commit
>
> 2e1c949 still exists and still has its parent set to 499724c, it's just
> that 2e1c949 is not reachable from, in this case, master. You can see this
> more explicitly in the log when specifying master and the dangling 2e1c949:
>
> $ git log --graph --oneline --decorate master 2e1c949 # two explicit
> places to start from
> * 94e441b (HEAD, master) Bar (edited)
> | * 2e1c949 Bar
> |/
> * 499724c Initial commit
>
> The two are separate, as you can see.
>
> As far as an actual answer concerning `prune` and `fsck`, I'm not quite
> sure but it may be something to do with the default length of time before
> an object will actually be pruned. I'd be interested in reading a fuller
> answer by someone who knows.
>
> --
> 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.
>

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

Reply via email to