Re: [PATCH] builtin/remote.c: teach `-v` to list filters for promisor remotes

From: Junio C Hamano <gitster@pobox.com>
Date: May 1, 2022, 16:14 UTC
Message-ID: <xmqqfslt44di.fsf@gitster.g>
In-Reply-To: <20220501155725.93866-1-chakrabortyabhradeep79@gmail.com>

Abhradeep Chakraborty <chakrabortyabhradeep79@gmail.com> writes:

Show 20 quoted lines

> Sorry for the late response.
>
> Junio C Hamano <gitster@pobox.com> wrote:
>
>> Three comments and a half on the code:
>>
>>  - Is it likely that to new readers it would be obvious that what is
>>    in the [square brackets] is the list-objects-filter used?  When we
>>    want to add new kinds of information other than the URL and the
>>    list-objects-filter, what is our plan to add them? 
>
> I do think that new readers can easily understand the meaning of the
> text inside the [square brackets]. These square brackets (with the
> list-objects-filter inside it) will be shown only if the remote is
> a promisor remote. So, users who don't use promisor remotes, will not
> be affected. Those who used the filters can only notice the change.
> They can easily understand it. In fact, I think it would give them an
> option to quickly check which are the promisor remotes and which are not.
> Though this change should be properly documented (which I forgot to
> add) so that they can be sure about it.

You forgot to answer more important half of the question. It would be easy for you to know what the string inside brackets means because you are so obsessed with the promisor remote to write this patch ;-) But when we need to add even more pieces of information in the future, will it stay so? Can "[some-random-string]" easily be identified as a list-objects-filter by those who do not care particularly about promisor remotes (e.g. those who wanted to see the URL to tell multiple remote nicknames apart) when the line has even more piece of information in the future?

At some point, we'd need to either (1) stop adding too many details to avoid cluttering the output line, or (2) start labeling each piece of information to make it easy for the readers to identify which one is which [*]. We need to ask ourselves why now is not that "some point" already.

    Side note: and the strategy to add new pieces of information
    need to take the same approach between the two, and that is why
    we need "what is the plan to add new pieces of information?"
    answered.

> (i.e. which are promisor remotes and which are not) one by one. If the
> user try to search for the promisor remotes in the config file, he/she
> have to go through the other configuration settings (irrelevant to him/her
> at that time) to reach the `[remote]` section. Isn't it?

Sorry, but the question does not make much sense to me. Why is a piece of information you get from "git config" irrelevant if you get it in order to figure out what you want to know, i.e. what promisor remote do we rely on?

Show 8 quoted lines

>> ...  If
>> it makes sense to add the extra <list-objects-filtrer> information,
>> that would mean that there are probably two remote nicknames that
>> refer to the same URL (i.e. "remote -v" readers cannot tell them
>> apart without extra information), but how likely is that, I wonder?
>
> I think, having a proper documentation about the new changes is the
> answer to it.

The question is "what can readers achieve by having this extra information in 'remote -v' output". Do you have to duck the question because you cannot answer in a simple sentence, and instead readers must read reams of documentation pages? I doubt it would be that obscure.

I wanted to like the patch, the changed text is simple enough, but quite honestly, the lack of clarity in the answers to the most basic "why do we want this? what is this good for? how does this help the users?" questions, I am not yet succeeding to do so.

Thanks.