Re: [GSoC PATCH v9 2/5] repo: add the field references.format
- From
- Phillip Wood <phillip.wood123@gmail.com>
- Date
- Aug 14, 2025, 13:58 UTC
- Message-ID
- <6731afaf-7036-4c8b-9479-80b6e2afa7e7@gmail.com>
- In-Reply-To
- <CAPig+cQUuXxz2gMMA200D39dqWi6wpu6z43Wkr_trbCwuvTKSA@mail.gmail.com>
On 13/08/2025 22:46, Eric Sunshine wrote:
Show 8 quoted lines
> On Wed, Aug 13, 2025 at 5:18 PM Lucas Seiki Oshiro > <lucasseikioshiro@gmail.com> 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
Show 16 quoted lines
>> 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