Re: [PATCH 2/2] help: ensure &keys_uniq follows sort -u

From: Junio C Hamano <gitster@pobox.com>
Date: Feb 12, 2026, 21:37 UTC
Message-ID: <xmqqcy29myo0.fsf@gitster.g>
In-Reply-To: <CAPvEtrenMBMFaMxcCR4VwoyMFU-_Z+bqq5nJaWv5eyn3HRutEA@mail.gmail.com>

Amisha Chhajed <amishhhaaaa@gmail.com> writes:

Show 7 quoted lines

> No, there is a case where it would not be sorted(keys_uniq won't be sorted
> even though keys is), more details on the case[0] and steps to reproduce[1].
> [0] https://lore.kernel.org/git/CAPvEtrfEZXHxcDf=z60ODfUA8cS81rhF1y7KEZApEBby7aCa1A@mail.gmail.com/
> [1] https://lore.kernel.org/git/20260212041017.91370-1-amishhhaaaa@gmail.com/T/#m64880c5cd0d36e35bc78692757cf206b13496aea
> only reason it is not causing a problem now is because we do not have
> this edge case appearing git documentation(from where the keys are built)
> but if someday a case like this appears there then it would cause problems.

Ah, if you already have a reproduction case , it would have been very good to add it as a new test. That way, we can (1) apply the patch, (2) tentatively revert only the code change, (3) build and run test to see that the test breaks, demonstrating an existing breakage, (4) restore the code change we tentatively reverted, (5) build and run test again to see that the existing breakage is now gone.

Show 12 quoted lines

>> This is not a performance critical part of the system, so it is OK
>> as a future-proof measure to sort keys_uniq immediately before we
>> start doing something that we _care_ about its sortedness (e.g.,
>> presenting the final output to the user), even if keys_uniq is known
>> to be already sorted with the current code.  Using sort_u here would
>> allow us not to worry about how keys_uniq is constructed in that
>> ugly loop.
>
> Agreed, we do not need to sort it twice if we decouple CONFIG_HUMAN
> from the rest of the switch case, that is a great way to go about it,
> thank you!.
> I will work on it.

Thanks.