Re: Looks like --amend create commit... don't understand
- From
Matthieu Moy <matthieu.moy@grenoble-inp.fr>
- Date
- Feb 24, 2010, 22:01 UTC
- Message-ID
- <vpqr5oa9tu5.fsf@bauges.imag.fr>
- In-Reply-To
- <4B8599C4.1050409@gmail.com>
mat <matthieu.stigler@gmail.com> writes:
> commits. But when looking on gitk, I see that > git commit blabla --amend > > does create each and every time a new commit,
Yes. In Git, objects (including commits) are fundamentally immutable. You never modify an object, you create a new one, and usually forget about the old one.
> I mean: with git log, > there is only one commit, but on gitk, I see many, with the same name > but different revision ID....
The revision ID is the sha1sum of the commit content. So, if they have different contents, they _must_ have different IDs.
What happens is that you start with a history like
A---B <- master
and then try to --amend B. What happens is that you create a new B, say B', and let the branch you sit on point to this new one. Like:
A---B \ `-B' <- master
Most of the time, B has just become unreachable: no branch contain it, no tag point to it, ... so you actually see
A---B' <- master
and it very much looks like you just modified B.
Now, if you made B reachable before your commit --amend, like by pushing it to another repo, letting someone else pull from it, or if B is already part of another branch, then the situation is different.
For example, if B is already part of a branch, like this:
.---- temp-branch
v
A---B---C <- masterIf you do a checkout of temp-branch, then commit --amend, you end up in this situation :
A---B---C <- master \ `-B' <- temp-branch
The solutions:
* If you already published your commit, then don't amend it. Period.
* If you want to rewrite an old commit in a branch, then read about "git rebase -i", but make sure you read all the warnings about rebase before you do so.
-- Matthieu Moy http://www-verimag.imag.fr/~moy/