On Sat, Mar 21, 2015 at 4:43 AM, Thomas Gummerer <t.gummerer@xxxxxxxxx> wrote: > The split index extension uses ewah bitmaps to mark index entries as > deleted, instead of removing them from the index directly. This can > result in an on-disk index, in which entries of stage #0 and higher > stages appear, which are removed later when the index bases are merged. > > 15999d0 read_index_from(): catch out of order entries when reading an > index file introduces a check which checks if the entries are in order > after each index entry is read in do_read_index. This check may however > fail when a split index is read. > > Fix this by moving checking the index after we know there is no split > index or after the split index bases are successfully merged instead. 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). If sorting order is messed up, it could lead to other problems. So instead of removing the test from do_read_index(), perhaps add a flag in check_ce_order() to optionally detect the stage problem, but print/do nothing, only set a flag so the caller know there may be a problem. In the two new call sites you added, we still call the new check_ce_order() again to make sure everything is in order. In the call site where split index is not active, if the previous check_ce_order() call from inside do_read_index() says "everything is ok", we could even skip the check. -- Duy -- 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