Re: [PATCH 6/6] refactor fetch's ref matching to use ref_abbrev_matches_full_with_rules()

[Jakub Narebski <jnareb@gmail.com>]

Steffen Prohaska wrote:

> The old rules used by fetch were coded as a series of ifs.  The old
> rules are:
> 1) match full refname if it starts with "refs/" or matches "HEAD"
> 2) verify that full refname starts with "refs/"
> 3) match abbreviated name in "refs/" if it starts with "heads/",
>     "tags/", or "remotes/".
> 4) match abbreviated name in "refs/heads/"
> 
> This is replaced by the new rules
> a) match full refname
> b) match abbreviated name prefixed with "refs/"
> c) match abbreviated name prefixed with "refs/heads/"
> 
> The details of the new rules are different from the old rules.  We no
> longer verify that the full refname starts with "refs/".  The new rule
> (a) matches any full string.  The old rules (1) and (2) were stricter.
> Now, the caller is responsible for using sensible full refnames.  This
> should be the case for the current code.  The new rule (b) is less
> strict than old rule (3).  The new rule accepts abbreviated names that
> start with a non-standard prefix below "refs/".
> 
> Despite this modifications the new rules should handle all cases as
> expected.  Two tests are added to verify that fetch does not resolve
> short tags or HEAD in remotes.
> 
> We may even think about loosening the rules a bit more and unify them
> with the rev-parse rules.  This would be done by replacing
> ref_ref_fetch_rules with ref_ref_parse_rules.  Note, the two new test
> would break.

Does still "origin" matches "origin/HEAD" if we have emote "origin"?

-- 
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git