Looks like --amend create commit... don't understand
Hi
Sorry for this question that might appear soo simple but I'm a little bit lost :-(
When editing my code, I like to --amend it a lot between bigger commits. But when looking on gitk, I see that git commit blabla --amend
does create each and every time a new commit, I mean: with git log, there is only one commit, but on gitk, I see many, with the same name but different revision ID.... My understanding was that it would only replace, not create each time a new revision.. Could you please explain me where Iàm wrong and what is happening exactly?
Furthermore, if I wish to delete all those intermediary amend commit, can I do it? If yes, how?
Thanks a lot for this help!
Matthieu
Quoted 4 lines · mat
I mean: with git log, there is only one commit, but on gitk, I see many, with the same name but different revision ID.... My understanding was that it would only replace, not create each time a new revision.. Could you please explain me where Iàm wrong and what is happening exactly?
Try doing "reload" (as opposed to just "update") using CTRL+F5 after you amend in order to see only the new commits, and ignore the old ones. If you have an old version of gitk, you might need to do it directly from the menu.
Quoted 4 lines · mat
commits. But when looking on gitk, I see that
git commit blabla --amenddoes 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.
Quoted 3 lines
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
vA---B---C <- master
If 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.
Signature · 2 lines
Matthieu Moy http://www-verimag.imag.fr/~moy/
Dear Matthieu
Thanks a lot for your patient help and clear explanations, it is now much clearer for me!
Merci!
Matthieu
Quoted 66 lines · Matthieu Moy
Quoted 5 lines · mat
commits. But when looking on gitk, I see that
git commit blabla --amenddoes 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.
Quoted 4 lines
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' <- masterMost 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 vA---B---C <- master
If you do a checkout of temp-branch, then commit --amend, you end up in this situation :
A---B---C <- master
\
`-B' <- temp-branchThe 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.