Re: [PATCH 4/9] get_short_oid: sort ambiguous objects by type, then SHA-1

[Derrick Stolee <stolee@gmail.com>]

On 5/1/2018 8:36 AM, Ævar Arnfjörð Bjarmason wrote:
> On Tue, May 01 2018, Derrick Stolee wrote:
>
>> How would sorting in our custom order before de-duplicating fail the
>> de-duplication? We will still pair identical OIDs as consecutive
>> elements and oid_array_for_each_unique only cares about consecutive
>> elements having distinct OIDs, not lex-ordered OIDs.
> Because there's no de-duplication without the array first being sorted
> in oidcmp() order, which oid_array_for_each_unique() checks for and
> re-sorts if !array->sorted. I.e. its de-duplication is just a state
> machine where it won't call the callback if the currently processed
> element has the same SHA1 as the last one.
>
>> Perhaps the noise is because we rely on oid_array_sort() to mark the
>> array as sorted inside oid_array_for_each_unique(), but that could be
>> remedied by calling our QSORT() inside for_each_abbrev() and marking
>> the array as sorted before calling oid_array_for_each_unique().
> As noted above this won't work, because the function inherently relies
> on the array being sorted to be able to de-duplicate. Doing this will
> yield duplicate entries.

I'm confused as to why my suggestion doesn't work, so I made it 
concrete. I sent an alternate commit 6/12 to your v2 series [1].

Thanks,
-Stolee

[1] 
https://public-inbox.org/git/20180501130318.58251-1-dstolee@microsoft.com/T/#u