Re: non-empty index with git commit -a

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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@xxxxxxxx> 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
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]