Duy Nguyen <pclouds@xxxxxxxxx> 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. -- 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