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

From: Junio C Hamano <gitster@pobox.com>
Date: Mar 24, 2015, 17:19 UTC
Message-ID: <xmqqpp7y71ox.fsf@gitster.dls.corp.google.com>
In-Reply-To: <CACsJy8CYi+hYu8zwOy=m7zZk3-8fr+Jq9uT4kEf8fLCOcjHJzw@mail.gmail.com>

Duy Nguyen <pclouds@gmail.com> writes:

Show 8 quoted lines

> 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.