Re: [PATCH v2] branch: improve error log on branch not found by checking remotes refs

> Clement Mabileau <mabileau.clement@gmail.com> writes:
>
> Ah, sorry, I didn't get your response as a conditional "if you like
> it, I'll work on it further", as we usually take "how deeply does
> the original proposer of a change believes in it" as a strong hint
> when we need to decide if it is something worth pursuing [*1*].  I
> am not so enthused to drop everything else and invest 100% of my
> time and attention to this change, but I am not opposed to the
> change being proposed, either.  We haven't seen anybody other than
> us two to speak on the review discussion thread of the previous
> round, so I do not know about other developers and users.

> The usual next step by the author is
>
>   * Update and resend the patch(es), taking care of not just
>     correctness of the code but also making sure that the proposed
>     log message reduces the need for those questions asked during the
>     review of the previous round [*2*].
>
>   * Wait to see other people who find the change favorable.
>
>   * After that, the patch may be picked up, advance to 'next' and
>     then to a future release.
>
> but the author can abandon it at any step.  After all it is author's
> itch and all we can do here on the list is to give encouragement and
> help in polishing it.
>
> Thanks.
> [Footnote]
>
> *1* We do not take it very kindly when somebody says "I am dreaming
>      this and that change, I think it would be great, and if you
>      promise it will be included in the next version of Git, I'll
>      work on it", and respond with "We do not know how good your
>      change will be until we see it." plus "If a change is so great,
>      we expect you would work on it even only for yourself,its
>      greatness will spread by word of the mouth, many people will
>      yearn for it, and eventually we would come to you begging."  A
>      change, in which even the original author does not feel it is
>      worth their time to invest to perfect, has much less chance to
>      be successful.

> *2* Reviews on the previous round may have asked "why is this change
>      needed?" "what is the intended use case?" etc.  The proposed log
>      message is the place to explain these.  The goal is to make it
>      easier for future readers of "git log" to understand so that
>      they do not need to ask these questions (unlike reviewers who
>      can ask and get answers from the author of the patch, they do
>      not have anybody to ask because the author of the patch may not
>      be around forever).