I have seen GIT commit --amend in detached HEAD state. The question requires the answer to be more complex than needs be. I'd like to understand just how git commit --amend
works in a normal HEAD situation.
Assume that you're in a clean working state and that your repo looks as follows:
If you then run
git commit --amend
write a commit message, save and quit your editor, the following happens:
f42c5
—is used to create a new commit: 31b8e
. Its parent(s) will be the same as that(those) of the commit you're amending: f42c5
.master
branch reference is moved to point to that new commit (31b8e
).HEAD
reference follows master
.Note that the amended commit (f42c5
) is now unreachable from any reference in your repo (hence its "transparent" style on my graph). It still lives in your repository's object database, but will eventually be deleted for good, when Git runs its periodic housekeeping, or if you trigger it explicitly by running git gc
(garbage collection).
Addendum (based on Jason Baker's comment): Note that, as long as the amended commit, f42c5
, still exists in your repo and you have a way of finding out its commit ID (for example, by fishing it out of the master
branch's reflog), you can still check it out. Running
git checkout master # just to be sure that master is the current branch
git reset --hard f42c5
or (assuming you haven't, in the meantime, made any new commit on master
, reset master
, or otherwise moved the master
branch reference)
git checkout master # just to be sure that master is the current branch
git reset --hard master@{1}
would put you in the following situation:
But now, commit 31b8e
would become unreachable.
Collected from the Internet
Please contact [email protected] to delete if infringement.
Comments