Re: [PATCH] ls-remote: a lone "-h" is asking for help

Subsystems: the rest

2 messages, 2 authors, 2016-06-15 · open the first message on its own page

Re: [PATCH] ls-remote: a lone "-h" is asking for help

From: Junio C Hamano <hidden>
Date: 2016-06-15 22:52:03

Sverre Rabbelier [off-list ref] writes:
On Fri, Sep 16, 2011 at 21:35, Junio C Hamano [off-list ref] wrote:
quoted
Sverre Rabbelier [off-list ref] writes:
quoted
Should we really have "-h" as a short for anything other than "--help"
in the first place?
...
Does git 2.0 count?
I am not opposed to. We should do the usual "start from warning and then
deprecate" dance, but I do not think we would want to have a "I want the
old behaviour, please keep it" configuration, especially if we are talking
about a big version bump like 2.0.

The first step would look something like this, on top of the previous
patch.

 builtin/ls-remote.c |    8 ++++++++
 1 files changed, 8 insertions(+), 0 deletions(-)
diff --git a/builtin/ls-remote.c b/builtin/ls-remote.c
index 41c88a9..dabe21e 100644
--- a/builtin/ls-remote.c
+++ b/builtin/ls-remote.c
@@ -28,6 +28,12 @@ static int tail_match(const char **pattern, const char *path)
 	return 0;
 }
 
+static void warn_h_deprecation(void)
+{
+	warning("Using -h as synonym for --heads is deprecated");
+	warning("and will be removed in future versions of Git.");
+}
+
 int cmd_ls_remote(int argc, const char **argv, const char *prefix)
 {
 	int i;
@@ -64,6 +70,8 @@ int cmd_ls_remote(int argc, const char **argv, const char *prefix)
 			}
 			if (!strcmp("--heads", arg) || !strcmp("-h", arg)) {
 				flags |= REF_HEADS;
+				if (!arg[2])
+					warn_h_deprecation();
 				continue;
 			}
 			if (!strcmp("--refs", arg)) {

Re: [PATCH] ls-remote: a lone "-h" is asking for help

From: Sverre Rabbelier <hidden>
Date: 2016-06-15 22:52:03

Heya,

On Fri, Sep 16, 2011 at 22:31, Junio C Hamano [off-list ref] wrote:
I am not opposed to. We should do the usual "start from warning and then
deprecate" dance, but I do not think we would want to have a "I want the
old behaviour, please keep it" configuration, especially if we are talking
about a big version bump like 2.0.

The first step would look something like this, on top of the previous
patch.
Makes sense.

I remember some sort of "this is for post 1.7.x" section in what's
cooking at some point. Should we have some way to queue patches like
this, or would someone have to resend after the appropriate release?

-- 
Cheers,

Sverre Rabbelier
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help