Re: [PATCH] Add shell completion for git remote rm

From: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
Date: Dec 29, 2017, 23:20 UTC
Message-ID: <87y3ll6s0e.fsf@evledraar.gmail.com>
In-Reply-To: <20171229224825.31062-1-szeder.dev@gmail.com>

On Fri, Dec 29 2017, SZEDER Gábor jotted:

Show 21 quoted lines

>> Keith Smiley wrote:
>> > It looks like that was just about preferring remove in documentation
>> > and the like, I think it would still make sense to have both for
>> > completion since rm is still supported.
>>
>> I read it as a first step in a long process to eventually
>> remove 'remote rm', but if that's never intended, then sure,
>> restoring completion for it seems reasonable.
>>
>> It would be good to hear from those who know or recall the
>> intention.
>>
>> I think we should only complete the preferred subcommand.
>> That encourages use of 'remote remove' even if 'remote rm'
>> will stay forever to avoid breaking existing scripts.
>
> Quoting from the commit message of e17dba8fe1 ("remote: prefer
> subcommand name 'remove' to 'rm'", 2012-09-06):
>
>   'rm' is still supported and used in the test suite. It's just not
>   widely advertised.

I think we made the wrong choice in standardizing on remove instead of rm, it should be rm for consistency with git-rm, and "remote rename" should be "remote mv" etc., just like we have git-mv.

Maybe if we didn't have the Unix legacy we'd pick rename and remove to be consitent for both, but since that's not going to happen this bit of inconsistency is worse.

Now with that showing of my biases out of the way...

> I think adding 'rm' to completion definitely counts as advertisement.
> It doesn't have much practical use, after all: typing 'rm' with
> completion is actually one more keystroke than without (r<TAB>m vs. rm).

This is only one use of the completion interface, maybe you only use it like that, but not everyone does.

The completion interface has two uses, one is to actually save you typing, the other is subcommand discovery, and maybe someone who has a use neither you or I have thought of is about to point out a third.

I'll type "git $whatever $subcommand<TAB>" as *validation* that I've found the right command, not to complete it for me. This is a thing that's in my muscle memory for everything.

The post-hoc reason is because if you're a fast typist you don't actually save time on typing the command (usually I just use reverse shell search anyway), but rather on not screwing up the command itself via a typo.

Sometimes commands take a while to fail, and even if it's immediate re-editing them takes longer than getting it right in the first place.

Since I've been typing "git remote rm<TAB>" for a while (started before this deprecation happened) I've actually been meaning to submit completion for "rm" since it works, not knowing about Duy's patch until now.

Now, even if someone disagrees that we should have "rm" at all I think that in general we should not conflate two different things, one is whether:

    git remote <TAB>

shows both "rm" and "remove" in the list, and the other is whether:

    git remote rm<TAB>

Should yield:

    git remote rm<SPACE>

Or, as now happens:

    git remote rm<NOTHING AND ÆVAR THINKS IT'S BROKEN>

I can see why we'd, in general, we'd like to not advertise certain options for completion (due to deprecation, or just to avoid verbosity), but complete them once they're unambiguously typed out.

I don't know whether the bash completion interface supports making that distinction, but it would be useful.