git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Re: [PATCH] refname_match(): always use the rules in ref_rev_parse_rules

From
Michael Haggerty <mhagger@alum.mit.edu>
Date
Jan 15, 2014, 16:54 UTC
Message-ID
<52D6BD62.4020307@alum.mit.edu>
In-Reply-To
<xmqq38kq43bx.fsf@gitster.dls.corp.google.com>
On 01/14/2014 11:16 PM, Junio C Hamano wrote:
Show 49 quoted lines
> Michael Haggerty <mhagger@alum.mit.edu> writes:
> 
>> We used to use two separate rules for the normal ref resolution
>> dwimming and dwimming done to decide which remote ref to grab.  The
>> third parameter to refname_match() selected which rules to use.
>>
>> When these two rules were harmonized in
>>
>>     2011-11-04 dd621df9cd refs DWIMmery: use the same rule for both "git fetch" and others
>>
>> , ref_fetch_rules was #defined to avoid potential breakages for
>> in-flight topics.
>>
>> It is now safe to remove the backwards-compatibility code, so remove
>> refname_match()'s third parameter, make ref_rev_parse_rules private to
>> refs.c, and remove ref_fetch_rules entirely.
>>
>> Suggested-by: Junio C Hamano <gitster@pobox.com>
>> Signed-off-by: Michael Haggerty <mhagger@alum.mit.edu>
>> ---
>> See
>>
>>     http://article.gmane.org/gmane.comp.version-control.git/240305
>>
>> in which Junio made the suggestion and wrote most of the commit
>> message :-)
> 
> ;-) ...and on top of it this may be an obvious endgame follow-up.
> 
> was done mindlessly and mechanically, so there may be some slip-ups,
> though.
> 
> 
>  refs.c | 24 +++++++++++++-----------
>  1 file changed, 13 insertions(+), 11 deletions(-)
> 
> diff --git a/refs.c b/refs.c
> index 5a10c25..b1c9cf5 100644
> --- a/refs.c
> +++ b/refs.c
> @@ -1886,16 +1886,16 @@ static const char *ref_rev_parse_rules[] = {
>  	"refs/tags/%.*s",
>  	"refs/heads/%.*s",
>  	"refs/remotes/%.*s",
> -	"refs/remotes/%.*s/HEAD",
> -	NULL
> +	"refs/remotes/%.*s/HEAD"
>  };
> [...rewrite loops to use ARRAY_SIZE()...]

It's doable, but I don't see the point. It's several lines longer (tho that's not significant either). The performance difference should be negligible. There are no users who benefit from knowing the length of the list ahead of time. If we ever decide to make the list vary at runtime your version won't help. Why bother?

Michael
-- 
Michael Haggerty
mhagger@alum.mit.edu
http://softwareswirl.blogspot.com/
Previous: Junio C Hamano
Message 11 of 11 in “Generate scanf_fmts more simply”
  1. 0/3 Generate scanf_fmts more simplyMichael Haggerty, Jan 8, 2014
  2. 1/3 shorten_unambiguous_ref(): introduce a new local variableMichael Haggerty, Jan 8, 2014
  3. 2/3 gen_scanf_fmt(): delete function and use snprintf() insteadMichael Haggerty, Jan 8, 2014
  4. Junio C HamanoJan 9, 2014
  5. 3/3 shorten_unambiguous_ref(): tighten up pointer arithmeticMichael Haggerty, Jan 8, 2014
  6. Junio C HamanoJan 9, 2014
  7. Michael HaggertyJan 10, 2014
  8. Junio C HamanoJan 10, 2014
  9. refname_match(): always use the rules in ref_rev_parse_rulesMichael Haggerty, Jan 14, 2014
  10. Junio C HamanoJan 14, 2014
  11. Michael HaggertyJan 15, 2014

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.