Re: [PATCH 0/4] Handling unmerged files with merged entries
- From
Junio C Hamano <gitster@pobox.com>
- Date
- Aug 21, 2014, 22:18 UTC
- Message-ID
- <xmqqbnrdqyex.fsf@gitster.dls.corp.google.com>
- In-Reply-To
- <53F63D2F.9060704@kdbg.org>
Johannes Sixt <j6t@kdbg.org> writes:
Show 16 quoted lines
> 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 ;-)