Re: [PATCH 6/6] refactor fetch's ref matching to use ref_abbrev_matches_full_with_rules()
Show 29 quoted lines
> 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