Re: [PATCH 3/3] shorten_unambiguous_ref(): tighten up pointer arithmetic

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

Michael Haggerty <mhagger@alum.mit.edu> writes:

> As for removing the third argument of refname_match(): although all
> callers pass it ref_ref_parse_rules, that array is sometimes passed to
> the function via the alias "ref_fetch_rules".  So I suppose somebody
> wanted to leave the way open to make these two rule sets diverge (though
> I don't know how likely that is to occur).

It is the other way around.  We used to use two separate rules for
the normal ref resolution dwimming and dwimming done to decide which
remote ref to grab.  For example, 'x' in 'git log x' can mean
'refs/remotes/x/HEAD', but 'git fetch origin x' would not grab
'refs/remotes/x/HEAD' at 'origin'.  Also, 'git fetch origin v1.0'
did not look into 'refs/tags/v1.0' in the 'origin' repository back
when these two rules were different.

This was originally done very much on purpose, in order to avoid
surprises and to discourage meaningless usage---you would not expect
us to be interested in the state of a third repository that was
observed by our 'origin' the last time (which we do not even know
when).

When we harmonized these two rules later and we #defined out
ref_fetch_rules away to avoid potential breakages for in-flight
topics.  The old synonym can now go safely.