Re: seperate commits for objects already updated in index?

> The background behind this is around beginning of February 2006,
> the thread "Two ideas" by Carl Worth.  And the current behaviour
> is defined by this commit.  I'll talk about a possible
> improvement but first, here is what it does:
> 
> commit 130fcca63fe8e7e087e7419907e018cbbaf434a3
> Author: Junio C Hamano <junkio@cox.net>
> Date:   Sun Feb 5 00:07:44 2006 -0800
> 
>     
>        2. refuses to run if named paths... are different in HEAD and
>           the index (ditto about reminding).  Added paths are OK.
>     
> 
> The check that prevents you from doing
> 
> 	$ edit A B
> 	$ git update-index A B
>         $ git commit -o B
> 
> is the rule #2, which I think could use further improvement.  It
> is to address the "committing skewed files" issue Carl brought
> up in that thread.
> 
> It might be better to further check if the working tree file is
> the same as the index, and to allow a commit in such a case.
> 
> The intent of rule #2 is to prevent this from happening:
> 
> 	$ edit A B
>         $ git update-index A B
>         $ edit B again
>         $ git commit -o B
> 
> When this happens, the real index will have _old_ contents of B
> that never was committed, and does not match what is in the
> index.  But after the commit, we will match the real index to
> what was committed, so we will _lose_ the index entry for B
> before the second edit you explicitly told git to remember by
> saying 'update-index'.
>