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

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

[mat]

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

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

[Matthieu Moy]

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/

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

[mat]

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 <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.
>
>   

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

[Octavio Alvarez]

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.