Re: [PATCH v8 4/4] cache-tree: Write updated cache-tree after commit

[Junio C Hamano <gitster@pobox.com>]

Duy Nguyen <pclouds@gmail.com> writes:

>> ....  If you do not
>> use the extra temporary file, you start from "index.lock" left by
>> "add -i", write the updated index into "index.lock" and if you fail
>> to write, you have to roll back the entire "index"---you lose the
>> option to use the index left by "add -i" without repopulated
>> cache-tree.  But in the index update context, I do not think such a
>> complexity is not necessary.  If something fails, we should fail and
>> roll back the entire "index".
>
> I probably look at the problem from a wrong angle. To me the result of
> "commit -p" is precious. I'm not a big user of "commit -p" myself as I
> prefer "add -p" but it's the same...

Oh, we agree that the result of "commit -p" is precious.

But the point of David's series is to change the definition of the
"precious result" to not just "commit is made as asked", but now
also to include that "the index the user will use for continued work
will have populated cache-tree".  The series thinks both are precious.

As you can probably read from my review responses, I am not sold to
the idea that spending extra cycles to pre-populate cache-tree is
100% good idea, but if we _were_ to accept that it is a good idea,
it logically follows that failing to populate cache-tree is just as
a failure as failing to commit.

In any case, it is unlikely for writing out the updated index with
refreshed cache-tree to fail and blow away the partially built index
(we do not even attempt to reopen/update if we cannot prepare
in-core cache-tree), so I do not think it is such a big deal either
way.