On Thu, Jul 11, 2013 at 6:39 PM, Thomas Gummerer <t.gumme...@gmail.com> wrote:
>> Question about the possibility of updating index file directly. If git
>> updates a few fields of an entry (but not entrycrc yet) and crashes,
>> the entry would become corrupt because its entrycrc does not match the
>> content. What do we do? Do we need to save a copy of the entry
>> somewhere in the index file (maybe in the conflict data section), so
>> that the reader can recover the index? Losing the index because of
>> bugs is big deal in my opinion. pre-v5 never faces this because we
>> keep the original copy til the end.
>> Maybe entrycrc should not cover stat fields and statcrc. It would make
>> refreshing safer. If the above happens during refresh, only statcrc is
>> corrupt and we can just refresh the entry. entrycrc still says the
>> other fields are good (and they are).
> The original idea was to change the lock-file for partial writing to
> make it work for this case.  The exact structure of the file still has
> to be defined, but generally it would be done in the following steps:
>   1. Write the changed entry to the lock-file
>   2. Change the entry in the index
>   3. If we succeed delete the lock-file (commit the transaction)
> If git crashes, and leaves the index corrupted, we can recover the
> information from the lock-file and write the new information to the
> index file and then delete the lock-file.

Ah makes sense. Still concerned about refreshing though. Updated files
are usually few while refreshed files could be a lot more, increasing
the cost at #1.
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to