git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: Junio C Hamano <gitster@pobox.com>
To: Clement Mabileau <mabileau.clement@gmail.com>
Cc: ClementMabileau via GitGitGadget <gitgitgadget@gmail.com>,
	git@vger.kernel.org
Subject: Re: [PATCH v2] branch: improve error log on branch not found by checking remotes refs
Date: Tue, 04 Apr 2023 09:24:58 -0700	[thread overview]
Message-ID: <xmqqmt3n1up1.fsf@gitster.g> (raw)
In-Reply-To: <ff7bb1f4-e35a-66ad-1116-6bb2b906fed3@gmail.com> (Clement Mabileau's message of "Tue, 4 Apr 2023 15:30:33 +0200")

Clement Mabileau <mabileau.clement@gmail.com> writes:

>> Now I hope you'll understand why I suggested this patch. Maybe I'm the
>> only one that ended up in this situation, in this case I'd understand
>> that you would no longer be interested in the patch!
>> However if you still are, I'll be happy to make the modification you
>> asked for.

I do not think I made any request to change anything, other than
what procedurally is necessary in order to record the authorship in
the resulting commit correctly.  I did question why the new behaviour
was an improvement and your response helped me understand the
motivation better.

> Well, it would be nice to have an answer in order to know if I should
> abandon this patch or not :)

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).

  reply	other threads:[~2023-04-04 16:25 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-03-22  9:42 [PATCH 0/2] branch: improve error log on branch not found by checking remotes refs ClementMabileau via GitGitGadget
2023-03-22  9:42 ` [PATCH 1/2] " ctmbl via GitGitGadget
2023-03-22  9:42 ` [PATCH 2/2] Fix mem leak in branch.c due to not-free newly added virtual_name variable ctmbl via GitGitGadget
2023-03-22 16:52   ` Junio C Hamano
2023-03-22 20:00     ` Clement Mabileau
2023-03-22 20:52       ` Junio C Hamano
2023-03-22 20:03 ` [PATCH v2] branch: improve error log on branch not found by checking remotes refs ClementMabileau via GitGitGadget
2023-03-22 22:25   ` Junio C Hamano
2023-03-23 15:51     ` Clement Mabileau
2023-04-04 13:30       ` Clement Mabileau
2023-04-04 16:24         ` Junio C Hamano [this message]
2023-04-05  9:15           ` Clement Mabileau
2023-04-05 11:43   ` [PATCH v3] " ClementMabileau via GitGitGadget

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: http://vger.kernel.org/majordomo-info.html

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=xmqqmt3n1up1.fsf@gitster.g \
    --to=gitster@pobox.com \
    --cc=git@vger.kernel.org \
    --cc=gitgitgadget@gmail.com \
    --cc=mabileau.clement@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://80x24.org/mirrors/git.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).