git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: Duy Nguyen <pclouds@gmail.com>
To: Junio C Hamano <gitster@pobox.com>
Cc: "Keith Smiley" <k@keith.so>,
	"Ævar Arnfjörð Bjarmason" <avarab@gmail.com>,
	"Todd Zullinger" <tmz@pobox.com>,
	"SZEDER Gábor" <szeder.dev@gmail.com>,
	"Git Mailing List" <git@vger.kernel.org>,
	"Kevin Daudt" <me@ikke.info>
Subject: Re: [PATCH] Add shell completion for git remote rm
Date: Wed, 17 Jan 2018 07:44:19 +0700	[thread overview]
Message-ID: <20180117004419.GA14263@duynguyen.dek-tpc.internal> (raw)
In-Reply-To: <xmqqh8rlvdgh.fsf@gitster.mtv.corp.google.com>

On Tue, Jan 16, 2018 at 10:57:34AM -0800, Junio C Hamano wrote:
> Duy Nguyen <pclouds@gmail.com> writes:
> 
> > On Tue, Jan 16, 2018 at 4:43 AM, Keith Smiley <k@keith.so> wrote:
> >> So it sounds like either we should deprecate rm, or I should update the patch to the suggested method where we just complete remotes, but not rm in the list of completions.
> >
> > I vote for deprecation. I could send a patch to start warning to
> > switch from 'rm' to 'remove'. Then perhaps we can delete it after two
> > releases. It's not classified as plumbing should we don't have worry
> > too much about scripts relying on 'remote rm'.
> 
> I do not know about "two releases" part (which amounts to merely
> 20-24 weeks), but looking at "git remote -h" output and seeing that
> we do spell out "rename" (instead of saying "mv" or something cryptic),
> it probably makes sense to remove "rm" some time in the future.
> 
> I actually do think "rm" is _already_ deprecated.  
> 
> "git remote --help" does not mention it in its synopsis section and
> it merely has ", rm" after "remove" as if an afterthought.

It's actually my bad. I should have replaced 'rm' with 'remove' in
git-remote.txt in e17dba8fe1 (remote: prefer subcommand name 'remove'
to 'rm' - 2012-09-06)

> I am not sure if it is worth being more explicit, perhaps like this?

Looks good. If we want to be more careful, we can follow up with
something even more annoying like this before removing 'rm'

-- 8< --
diff --git a/Documentation/git-remote.txt b/Documentation/git-remote.txt
index 577b969c1b..0a544703e6 100644
--- a/Documentation/git-remote.txt
+++ b/Documentation/git-remote.txt
@@ -90,7 +90,6 @@ In case <old> and <new> are the same, and <old> is a file under
 the configuration file format.
 
 'remove'::
-'rm'::
 
 Remove the remote named <name>. All remote-tracking branches and
 configuration settings for the remote are removed.
diff --git a/builtin/remote.c b/builtin/remote.c
index d95bf904c3..774ef6931e 100644
--- a/builtin/remote.c
+++ b/builtin/remote.c
@@ -1609,7 +1609,10 @@ int cmd_remote(int argc, const char **argv, const char *prefix)
 		result = add(argc, argv);
 	else if (!strcmp(argv[0], "rename"))
 		result = mv(argc, argv);
-	else if (!strcmp(argv[0], "rm") || !strcmp(argv[0], "remove"))
+	else if (!strcmp(argv[0], "rm")) {
+		warning(_("'rm' is a deprecated synonym. Use 'remove' instead."));
+		result = rm(argc, argv);
+	} else if (!strcmp(argv[0], "remove"))
 		result = rm(argc, argv);
 	else if (!strcmp(argv[0], "set-head"))
 		result = set_head(argc, argv);
-- 8< --

PS. This also makes me thing about supporting subcommand aliases, so
that people can add back 'git remote rm' if they like (or something
like 'git r rm' when they alias 'remote' as well). Which is probably a
good thing to do. Long command names are fine when you have completion
support, they are a pain to type otherwise.

--
Duy

  reply	other threads:[~2018-01-17  0:44 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-12-29  2:01 [PATCH] Add shell completion for git remote rm Keith Smiley
2017-12-29  3:29 ` Todd Zullinger
2017-12-29  4:19   ` Keith Smiley
2017-12-29 13:52     ` Todd Zullinger
2017-12-29 16:49       ` [PATCH] completion: restore 'remote rm' Keith Smiley
2017-12-29 22:48       ` [PATCH] Add shell completion for git remote rm SZEDER Gábor
2017-12-29 23:19         ` Keith Smiley
2017-12-29 23:20         ` Ævar Arnfjörð Bjarmason
2017-12-30  0:52           ` Todd Zullinger
2017-12-30 12:19             ` Ævar Arnfjörð Bjarmason
2017-12-31 20:44               ` Keith Smiley
2018-01-03 19:24               ` Junio C Hamano
2018-01-15 21:43                 ` Keith Smiley
2018-01-16 10:02                   ` Duy Nguyen
2018-01-16 18:57                     ` Junio C Hamano
2018-01-17  0:44                       ` Duy Nguyen [this message]
2018-01-17  6:17                         ` Kevin Daudt
2018-01-17  9:48                           ` Duy Nguyen
2018-07-16 13:12                             ` Keith Smiley
2018-01-17 18:20                         ` Junio C Hamano
2018-01-01 23:46     ` Duy Nguyen
2017-12-29  6:00 ` Kevin Daudt
2017-12-29  6:21   ` Keith Smiley

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=20180117004419.GA14263@duynguyen.dek-tpc.internal \
    --to=pclouds@gmail.com \
    --cc=avarab@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=k@keith.so \
    --cc=me@ikke.info \
    --cc=szeder.dev@gmail.com \
    --cc=tmz@pobox.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).