From: Junio C Hamano <gitster@pobox.com>
Date: Thu, 21 Aug 2014 22:18:46 GMT
Subject: Re: [PATCH 0/4] Handling unmerged files with merged entries
Message-ID: <xmqqbnrdqyex.fsf@gitster.dls.corp.google.com>
In-Reply-To: <53F63D2F.9060704@kdbg.org>

Johannes Sixt <j6t@kdbg.org> 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
;-)