Thread (1 message) 1 message, 1 author, 2016-06-15

Re: [PATCH 0/4] Handling unmerged files with merged entries

From: Junio C Hamano <hidden>
Date: 2016-06-15 23:02:19

Johannes Sixt [off-list ref] writes:
Am 21.08.2014 00:19, schrieb Junio C Hamano:
quoted
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
;-)
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help