Re: [PATCH 2/2] read-cache: fix reading of split index

Duy Nguyen [off-list ref] writes:

Thank you for catching this. I was about to write "would be nice to
point out what tests fail so the reviewer has easier time trying
themselves", but whoa.. quite a few of them!

May I suggest a slight modification. Even though stage info is messed
up before the index is merged, I think we should still check that both
front and base indexes have all the names sorted correctly (and even
stronger, the base index should never contain staged entries).

I smell a slight layering violation here, though.  As far as the
code to check the validity of the index is concerned, it is only
about the in-core index other code uses at runtime, and how that
in-core index is prepared, and most importantly, what is recorded in
the istate before it gets ready to be used by other code, is not its
concern.  The state immediately after the base index is read but
before it gets fixed up by the split-index code can have quirks
specific to how split-index code does things and it is perfectly OK
if it does not pass the check for the final shape.

The above does not change if the current split-index code happens to
promise certain properties in that intermediate state.  It is fine
if the split-index codepath wants to add its own validator to the
intermediate state for added robustness, but the rules for the
intermediate state and the rules for the final state can be
different, and from the maintainability's point of view, it is
better if we keep the validator for the final-shape oblivious to
what split-index does.