Re: [PATCH] man: git pull -r is a short for --rebase

From: Junio C Hamano <gitster@pobox.com>
Date: Aug 16, 2012, 20:21 UTC
Message-ID: <7vobma1tb9.fsf@alter.siamese.dyndns.org>
In-Reply-To: <20120816194552.GA3167@suse.cz>

Miklos Vajna <vmiklos@suse.cz> writes:

Show 9 quoted lines

> On Thu, Aug 16, 2012 at 09:22:14AM -0700, Junio C Hamano <gitster@pobox.com> wrote:
>> I am not sure if this is worth it, as it comes from a natural
>> "abbreviated options" support, i.e.
>> 
>> 	-r|--r|--re|--reb|--reba|--rebas|--rebase)
>> 		rebase=true
>
> I sent the patch as a (newcomer) friend today asked if it's intentional
> that -r is undocumented in 'man git-pull'.

It is more intentional than it is by accident that we don't.

We would really think hard to avoid breaking when introducing new options whose long name could begin with "v" or "q" to avoid breaking "-v" and "-q" that are common across commands, but it is entirely plausible that we want to add a new option whose name begins with "re", and at that point, "-r" or "--re" stop being the unique short form to trigger "git pull --rebase".

If somebody figures out "git pull --reba" or even "git pull -r" works by accident _today_ and gets used to using it, that is fine, but we do not want to guarantee the future. We reserve the right to introduce "git pull --repurpose" in a later version of Git, and make "git pull --re" error out for ambiguity, breaking fingers of such people who relied on "used to be but no longer" unique abbreviations.

> ...
> I agree, however, we already document -q and --quiet, or -v and
> --verbose in the same manpage, so I think it would be consistent to have
> -r there as well.

See above.

Thanks.