From: Junio C Hamano <gitster@pobox.com>
To: "Rubén Justo" <rjusto@gmail.com>
Cc: git@vger.kernel.org
Subject: Re: [PATCH] branch: do not fail a no-op --edit-desc
Date: Thu, 29 Sep 2022 15:26:01 -0700 [thread overview]
Message-ID: <xmqq7d1lom12.fsf@gitster.g> (raw)
In-Reply-To: <ba8a503b-76e2-5de9-1082-3b4c6ecd0cc3@gmail.com> ("Rubén Justo"'s message of "Thu, 29 Sep 2022 23:49:50 +0200")
Rubén Justo <rjusto@gmail.com> writes:
> Let me try again, I think my review was not good :-)
>
> On 28/9/22 21:15, Junio C Hamano wrote:
>> In a repository on a branch without branch description, try running
>
> It is a bit confusing the construction "a repository on a branch
> without branch description" as "branch" have "repository" inherent.
> So "On a branch without description.." holds the same meaning with less
> distracting words.
Ah, no, I did not mean a repository is on any branch. I meant
Go into a repository and be on a branch. That branch has to be
without branch description set. Now, try running these...
I think the easiest clarification is to drop "In a repository"
altogether.
> But.. do we want to implement this this way? Maybe we will have to
> implement on purpose this feature in some future refactorization?
Absolutely. It is simpler and there is not much downside.
> And.. the message does not make it clear the situation: if there is
> a previous description, will clear; if not, will keep.
If there is a previous description, then we use the behaviour we
have had for ages (i.e. will remove). If there is not a previous
description, then we use the new behaviour (i.e. not attempt to
remove and hence we do not show an error). Either way, the end
result is "the user indicated they do not want description by giving
us an empty edit result. After the command exits, the branch has no
description".
> If we want that feature, should we test for it? (do not take
> the snippet as tested...):
Notice the air-quotes around "feature" ;-)
The official stance is "if it hurts, do not do it then". The side
discussion about TOCTOU was to see how much hurt we are making the
user responsible for, and explaining that it is not that much.
next prev parent reply other threads:[~2022-09-29 22:26 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-09-28 19:15 [PATCH] branch: do not fail a no-op --edit-desc Junio C Hamano
2022-09-28 23:04 ` Rubén Justo
2022-09-28 23:40 ` Junio C Hamano
2022-09-29 21:49 ` Rubén Justo
2022-09-29 22:26 ` Junio C Hamano [this message]
2022-09-30 22:59 ` Rubén Justo
2022-10-01 9:15 ` Rubén Justo
2022-09-30 1:27 ` [PATCH v2] " Junio C Hamano
2022-09-30 10:21 ` Ævar Arnfjörð Bjarmason
2022-09-30 17:01 ` Junio C Hamano
2022-09-30 17:58 ` Ævar Arnfjörð Bjarmason
2022-09-30 18:13 ` Junio C Hamano
2022-09-30 18:06 ` [PATCH v3] " Junio C Hamano
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
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=xmqq7d1lom12.fsf@gitster.g \
--to=gitster@pobox.com \
--cc=git@vger.kernel.org \
--cc=rjusto@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.
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 NNTP newsgroup(s).