On 13/08/2025 22:46, Eric Sunshine wrote:

On Wed, Aug 13, 2025 at 5:18 PM Lucas Seiki Oshiro
[off-list ref] wrote:

I don't think that Phillip was suggesting dropping only the reordering
while keeping the deduplication; he was merely giving an example of an
alternative implementation which would accomplish the deduplication
goal, so he wasn't asking to over-engineer. Instead, (according to my
reading), he is suggesting dropping both deduplication and reordering.

Exactly

quoted

If I follow
this path of returning the values in the same order they were in the
command line, I think it would be better to just allow duplicated keys
and multiple "key not found" errors for the same unknown key instead
of increasing the complexity of this command.

What do you think?

I think that's exactly what Phillip was suggesting: present output in
order requested, no deduplication

I had suggested the same back in [*], but I also said that I could
formulate arguments in favor of either behavior, so I didn't have a
strong opinion. However, Phillip has presented a good reason to prefer
"output in order requested, no deduplication", and I do find his
argument compelling.

If this command was producing output primarily for human consumption 
then I think the argument for sorting and de-duplicating the output 
would be much stronger. However, as this command is intended to replace 
some uses of "git rev-parse" in scripts, I think that "output in order 
requested, no de-duplication" is more convenient.

Thanks

Phillip