Miklos Vajna <vmik...@suse.cz> writes:
> On Thu, Aug 16, 2012 at 09:22:14AM -0700, Junio C Hamano <gits...@pobox.com>
>> I am not sure if this is worth it, as it comes from a natural
>> "abbreviated options" support, i.e.
> 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
> 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.
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html