From: Junio C Hamano <gitster@pobox.com>
To: "Rubén Justo" <rjusto@gmail.com>
Cc: Git List <git@vger.kernel.org>
Subject: Re: [PATCH] branch: error description when deleting a not fully merged branch
Date: Wed, 10 Jan 2024 13:46:22 -0800 [thread overview]
Message-ID: <xmqqr0io980h.fsf@gitster.g> (raw)
In-Reply-To: <xmqqbk9tcc57.fsf@gitster.g> (Junio C. Hamano's message of "Wed, 10 Jan 2024 09:48:52 -0800")
Junio C Hamano <gitster@pobox.com> writes:
> This is probably one sensible step forward, so let's queue it as-is.
>
> But with reservations for longer-term future direction. Stepping
> back a bit, when 'foo' is not fully merged and the user used "branch
> -d" on it, is it sensible for us to suggest use of "branch -D"?
>
> Especially now this is a "hint" to help less experienced folks, it
> may be helpful to suggest how the user can answer "If you are sure
> you want to delete" part. As this knows what unique commits on the
> branch being deleted are about to be lost, one way to do so may be
> to tell the user about them ("you are about to lose 'branch: error
> description when deleting a not fully merged branch' and other 47
> commits that are not merged the target branch 'main'", for example).
>
> Another possibility is to suggest merging the branch into the
> target, instead of suggesting a destructive "deletion", but I
> suspect that it goes too far second-guessing the end-user intention.
The longer-term concerns aside, if you are inclined, we might want
to have this as a two step series, where [1/2] does a clean-up of
existing source file, i.e. losing the unwanted leading space from "
enum advice_type {" in advice.h and sort the advice.*:: list in
Documentation/config/advice.txt. It is optional to sort the
advice_setting[] list in advice.c and "enum advice_type" in
advice.h, as they are not end-user facing, and we should be using
the defined constant without relying on their exact values. But
keeping the config/advice.txt sorted would help readers more easily
locate which configuration variable to use to squelch a message.
And [2/2] does the rest.
Also I forgot that in the version I queued, I fixed the title to
branch: make the advice to force-deleting a conditional one
Thanks.
next prev parent reply other threads:[~2024-01-10 21:46 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-01-10 14:55 [PATCH] branch: error description when deleting a not fully merged branch Rubén Justo
2024-01-10 17:48 ` Junio C Hamano
2024-01-10 21:46 ` Junio C Hamano [this message]
2024-01-11 13:39 ` Rubén Justo
2024-01-11 12:20 ` [PATCH v2 0/3] " Rubén Justo
2024-01-11 12:40 ` [PATCH v2 1/3] advice: sort the advice related lists Rubén Justo
2024-01-11 12:40 ` [PATCH v2 2/3] advice: fix an unexpected leading space Rubén Justo
2024-01-12 1:21 ` Junio C Hamano
2024-01-12 9:10 ` Rubén Justo
2024-01-12 17:52 ` Junio C Hamano
2024-01-12 21:19 ` Junio C Hamano
2024-01-11 12:40 ` [PATCH v2 3/3] branch: make the advice to force-deleting a conditional one Rubén Justo
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=xmqqr0io980h.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.