threads / discuss / 22806

Looks like --amend create commit... don't understand

Subject: Looks like --amend create commit... don't understand

## tl;dr

4 messages between Feb 24, 2010 and Feb 25, 2010.

replies: 3people: 3as markdown or json

mat· Feb 24, 2010, 21:27 UTC · lore

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· Feb 24, 2010, 22:01 UTC · re: mat · lore

Re: Looks like --amend create commit... don't understand

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 <- 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· Feb 25, 2010, 20:45 UTC · re: Matthieu Moy · lore

Re: Looks like --amend create commit... don't understand

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 :

Show 66 quoted lines

> 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 <- 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· Feb 25, 2010, 22:25 UTC · re: mat · lore

Re: Looks like --amend create commit... don't understand

On Wed, 24 Feb 2010 13:27:32 -0800, mat <matthieu.stigler@gmail.com> 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.