Johannes Sixt <j6t@xxxxxxxx> writes: > Am 21.08.2014 00:19, schrieb Junio C Hamano: >> For that, we need to catch an index whose entries are not sorted and >> error out, perhaps when read_index_from() iterates over the mmapped >> index entries. We can even draw that "hopelessly corrupt" line >> above the breakage you are addressing and add a check to make sure >> no path has both merged and unmerged entries to the same check to >> make it error out. > > Except that we can't declare an index with both merged and unmerged > entries as "hopelessly corrupt, return to sender" when it's dead easy to > generate with the git tool set: > > >x > name=$(git hash-object -w x) > for i in 0 1 2 3; do printf '100644 %s %d\tx\n' $name $i; done | > git update-index --index-info Because hash-object and update-index deliberately have these holes to allow us (read: me ;-) to easily experiment new and/or unallowed formats, I wouldn't take that as a serious objection. It is dead easy to corrupt your repository or lose your data by /bin/rm, too ;-) -- 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