Abhradeep Chakraborty <chakrabortyabhradeep79@xxxxxxxxx> writes:
> Sorry for the late response.
>
> Junio C Hamano <gitster@xxxxxxxxx> 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?
>> ... 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.
