Am 09.05.20 um 09:16 schrieb Johannes Schindelin: > Hi, > > On Sat, 9 May 2020, René Scharfe wrote: > >> Am 09.05.20 um 08:19 schrieb Brandon Williams: >>> Here's the setup: >>> tree c63d067eaeed0cbc68b7e4fdf40d267c6b152fe8 >>> tree 6241ab2a5314798183b5c4ee8a7b0ccd12c651e6 >>> blob 5e1c309dae7f45e0f39b1bf3ac3cd9db12e7d689 >>> >>> $ git ls-tree c63d067eaeed0cbc68b7e4fdf40d267c6b152fe8 >>> 100644 blob 5e1c309dae7f45e0f39b1bf3ac3cd9db12e7d689 hello >>> 100644 blob 5e1c309dae7f45e0f39b1bf3ac3cd9db12e7d689 hello.c >>> 040000 tree 6241ab2a5314798183b5c4ee8a7b0ccd12c651e6 hello >> >>> Am I correct in assuming that this object is indeed invalid and should be >>> rejected by fsck? >> >> I'd say yes twice -- what good is a tree that you can't check out because >> it contains a d/f conflict? >> >> So I got curious if such trees might be in popular repos, wrote the patch >> below and checked around a bit, but couldn't find any. >> >> Is there a smarter way to check for duplicates? One that doesn't need >> allocations? Perhaps by having a version of tree_entry_extract() that >> seeks backwards somehow? > > Maybe we should verify that the entries are sorted? That would not need > any allocation, and it could even use the return value of the same > comparison we already perform to check for duplicates. Yes, but the key question is: Sorted by what? Tree entries are sorted by name, only that a slash is appended implicitly to the name of entries of type tree. The current code already checks for duplicates by comparing neighboring entries' names. That's not sufficient to find duplicates that differ in type, as Brandon's example above shows (which is sorted correctly). René
