# Looks like --amend create commit... don't understand 4 messages from 2010-02-24 to 2010-02-25. Participants: mat, Matthieu Moy, Octavio Alvarez. Thread: https://gitlist.dev/t/22806 ## mat, 2010-02-24 21:27 Subject: Looks like --amend create commit... don't understand Message-ID: <4B8599C4.1050409@gmail.com> URL: https://gitlist.dev/e/4B8599C4.1050409%40gmail.com ``` 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 ``` ## Matthieu Moy, 2010-02-24 22:01 Subject: Re: Looks like --amend create commit... don't understand Message-ID: URL: https://gitlist.dev/e/vpqr5oa9tu5.fsf%40bauges.imag.fr In-Reply-To: <4B8599C4.1050409@gmail.com> ``` mat 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 <- 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. -- Matthieu Moy http://www-verimag.imag.fr/~moy/ ``` ## mat, 2010-02-25 20:45 Subject: Re: Looks like --amend create commit... don't understand Message-ID: <4B86E152.1060108@gmail.com> URL: https://gitlist.dev/e/4B86E152.1060108%40gmail.com In-Reply-To: ``` Dear Matthieu Thanks a lot for your patient help and clear explanations, it is now much clearer for me! Merci! Matthieu Matthieu Moy a écrit : > mat 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 <- 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. > > ``` ## Octavio Alvarez, 2010-02-25 22:25 Subject: Re: Looks like --amend create commit... don't understand Message-ID: URL: https://gitlist.dev/e/op.u8pe8ovd4oyyg1%40alvarezp-ws In-Reply-To: <4B8599C4.1050409@gmail.com> ``` On Wed, 24 Feb 2010 13:27:32 -0800, mat wrote: > 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. ```