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

From: Junio C Hamano <gitster@pobox.com>
Date: Jan 10, 2014, 18:03 UTC
Message-ID: <xmqqlhyn90ka.fsf@gitster.dls.corp.google.com>
In-Reply-To: <52D000CC.1060402@alum.mit.edu>

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

Show 5 quoted lines

> 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.