Jonathan Tan writes:
> This looks good to me. I've checked that refname_match (and
> branch_merge_matches(), which returns the result of refname_match()
> directly) is only used in "if" contexts, so making it return a value
> other than 1 is fine.
Yes, the log message should say that existing
> That is, something like this, perhaps. The resulting behaviour
> should match how "git rev-parse X" would give precedence to tag X
> over branch X by going this route. What do you think?
[snip]
> static const struct ref *find_ref_by_name_abbrev(const struct ref *refs,
> const char *name)
>
Junio C Hamano writes:
> In order to resolve this correctly with the precedence rules, I
> think you need to make refname_match() return the precedence number
> (e.g. give 1 to "%.*s", 2 to "refs/%.*s", etc., using the index in
> ref_rev_parse_rules[] array), and make this loop keep track of the
Jonathan Tan writes:
> When matching a non-wildcard LHS of a refspec against a list of refs,
> find_ref_by_name_abbrev() returns the first ref that matches using the
> DWIM rules used by refname_match() in refs.c, even if an exact match
> occurs later in the list of refs.
When you have
Hi,
Jonathan Tan wrote:
> When matching a non-wildcard LHS of a refspec against a list of refs,
> find_ref_by_name_abbrev() returns the first ref that matches using the
> DWIM rules used by refname_match() in refs.c, even if an exact match
> occurs later in the list of refs.
>
> This causes
5 matches
Mail list logo
