Re: non-empty index with git commit -a

[Michael J Gruber <git@drmicha.warpmail.net>]

Jeff King venit, vidit, dixit 16.02.2011 11:06:
> On Wed, Feb 16, 2011 at 09:58:52AM +0000, Sverre Rabbelier wrote:
> 
>> On Wed, Feb 16, 2011 at 09:54, Jeff King <peff@peff.net> wrote:
>>> So? Your question was whether index state is precious. If it's precious,
>>> shouldn't we be keeping a history of it?
>>
>> I don't think it's quite _that_ precious, but the only operation that
>> I regularly use that can blow away my carefully constructed index as
>> side effect of doing something else is `git commit -a`.
> 
> OK, so how precious is it? :)

Maybe it's a bit precious, but not overly...

> 
> If you want to have an option that specifically prevents the "git commit
> -a" muscle memory thing, then go for it. I'm guessing it is the most
> common "oops" one. Even with an index reflog, you might want it on top.
> 
> But it just seems silly to me to not protect at the same time against
> the other ways you can lose state from the index.
> 
> -Peff

so that keeping one backup would be enough? I.e. an automated way of
doing "cp index index.bak" before an index update and some "reset"
incarnation to revive the copy?

Michael