On Fri, Dec 29 2017, SZEDER Gábor jotted:
>> 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.
