just peeked at the source files and noticed this text which may relate to some questions you had about pruning:
"The optional configuration variable 'gc.reflogExpireUnreachable' can be set to indicate how long historical reflog entries which are not part of the current branch should remain available in this repository. These types of entries are generally created as a result of using `git commit --amend` or `git rebase` and are the commits prior to the amend or rebase occurring. Since these changes are not part of the current project most users will want to expire them sooner. This option defaults to '30 days'...." Search "amend" (587 hits in 95 files) if you want to dig in! :) On Thu, Sep 27, 2012 at 9:22 PM, Max Hodges <m...@whiterabbitpress.com>wrote: > 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.
