Re: The fetch command should "always" honor remote.<name>.fetch

[Junio C Hamano <gitster@pobox.com>]

Lewis Diamond <git@lewisdiamond.com> writes:

> ... Yes, I agree that the abbreviation expansion works as designed
> (using the rev_parse_rules), 

I am not fundamentally opposed if you want to add a new command line
option to "git fetch" so that the shortened "what to fetch" are
dwimmed differently, but changing how "git fetch there master"
without any such option behaves will not fly well.  It will break
those who have already learned Git who expect that that is the way
to explicitly ask to fetch the master branch regardless of what
configuration the repository might have.

It is true that "git fetch there 'master'" cannot possibly mean the
'master' branch we locally have, so there is no fundamental reason
why we should use the same rev-parse dwim rules to grok them.

In fact we used to have different dwim rules for local (rev-parse
dwim rules) and for remote access --- I do not offhand recall if we
had rules for push and fetch separately, but I wouldn't be surprised
if we did.  The underlying mechanism certainly allowed us to use
separate rules for them back then.

Over time, however, having separate rules for remote and local was
found confusing by users, and that is why we changed the code to use
the same rule everywhere when dwimming the abbreviated refname on
the command line these days.