All of lore.kernel.org
 help / color / mirror / Atom feed
From: Junio C Hamano <gitster@pobox.com>
To: "Rafael Ascensão" <rafa.almas@gmail.com>
Cc: git@vger.kernel.org, me@ikke.info, hjemli@gmail.com,
	mhagger@alum.mit.edu, pclouds@gmail.com,
	ilari.liusvaara@elisanet.fi
Subject: Re: [PATCH v1 1/2] refs: extract function to normalize partial refs
Date: Sat, 04 Nov 2017 11:27:39 +0900	[thread overview]
Message-ID: <xmqqo9oiok10.fsf@gitster.mtv.corp.google.com> (raw)
In-Reply-To: <20171104004144.5975-2-rafa.almas@gmail.com> ("Rafael =?utf-8?Q?Ascens=C3=A3o=22's?= message of "Sat, 4 Nov 2017 00:41:43 +0000")

Rafael Ascensão <rafa.almas@gmail.com> writes:

> `for_each_glob_ref_in` has some code built into it that converts
> partial refs like 'heads/master' to their full qualified form

s/full/&y/ (read: that "full" needs "y" at the end).

> 'refs/heads/master'. It also assume a trailing '/*' if no glob

s/assume/&s/

> characters are present in the pattern.
>
> Extract that logic to its own function which can be reused elsewhere
> where the same behaviour is needed, and add an ENSURE_GLOB flag
> to toggle if a trailing '/*' is to be appended to the result.
>
> Signed-off-by: Kevin Daudt <me@ikke.info>
> Signed-off-by: Rafael Ascensão <rafa.almas@gmail.com>

Could you explain Kevin's sign-off we see above?  It is a bit
unusual (I am not yet saying it is wrong---I cannot judge until I
find out why it is there) to see a patch from person X with sign off
from person Y and then person X in that order.  It is normal for a
patch authored by person X to have sign-off by X and then Y if X
wrote it, signed it off and passed to Y, and then Y resent it after
signing it off (while preserving the authorship of X by adding an
in-body From: header), but I do not think that is what we have here.

It could be that you did pretty much all the work on this patch
and Kevin helped you to polish this patch off-list, in which case
the usual thing to do is to use "Helped-by: Kevin" instead.

> ---
>  refs.c | 34 ++++++++++++++++++++--------------
>  refs.h | 16 ++++++++++++++++
>  2 files changed, 36 insertions(+), 14 deletions(-)
>
> diff --git a/refs.c b/refs.c
> index c590a992f..1e74b48e6 100644
> --- a/refs.c
> +++ b/refs.c
> @@ -369,32 +369,38 @@ int head_ref_namespaced(each_ref_fn fn, void *cb_data)
>  	return ret;
>  }
>  
> -int for_each_glob_ref_in(each_ref_fn fn, const char *pattern,
> -	const char *prefix, void *cb_data)
> +void normalize_glob_ref(struct strbuf *normalized_pattern, const char *prefix,
> +		const char *pattern, int flags)

It is better to use "unsigned" for a single word "flags" used as a
collection of bits.  In older parts of the codebase, we have
codepaths that pass signed int as a flags word, simply because we
didn't know better, but we do not have to spread that practice to
new code.

>  {
> -	struct strbuf real_pattern = STRBUF_INIT;
> -	struct ref_filter filter;
> -	int ret;
> -
>  	if (!prefix && !starts_with(pattern, "refs/"))
> -		strbuf_addstr(&real_pattern, "refs/");
> +		strbuf_addstr(normalized_pattern, "refs/");
>  	else if (prefix)
> -		strbuf_addstr(&real_pattern, prefix);
> -	strbuf_addstr(&real_pattern, pattern);
> +		strbuf_addstr(normalized_pattern, prefix);
> +	strbuf_addstr(normalized_pattern, pattern);
>  
> -	if (!has_glob_specials(pattern)) {
> +	if (!has_glob_specials(pattern) && (flags & ENSURE_GLOB)) {
>  		/* Append implied '/' '*' if not present. */
> -		strbuf_complete(&real_pattern, '/');
> +		strbuf_complete(normalized_pattern, '/');
>  		/* No need to check for '*', there is none. */
> -		strbuf_addch(&real_pattern, '*');
> +		strbuf_addch(normalized_pattern, '*');
>  	}
> +}

The above looks like a pure and regression-free code movement (plus
a small new feature) that is faithful to the original, which is good.

I however notice that addition of /* to the tail is trying to be
careful by using strbuf_complete('/'), but prefixing with "refs/"
does not and we would end up with a double-slash if pattern begins
with a slash.  The contract between the caller of this function (or
its original, which is for_each_glob_ref_in()) and the callee is
that prefix must not begin with '/', so it may be OK, but we might
want to add "if (*pattern == '/') BUG(...)" at the beginning.  

I dunno.  In any case, that is totally outside the scope of this two
patch series.

> diff --git a/refs.h b/refs.h
> index a02b628c8..9f9a8bb27 100644
> --- a/refs.h
> +++ b/refs.h
> @@ -312,6 +312,22 @@ int for_each_namespaced_ref(each_ref_fn fn, void *cb_data);
>  int refs_for_each_rawref(struct ref_store *refs, each_ref_fn fn, void *cb_data);
>  int for_each_rawref(each_ref_fn fn, void *cb_data);
>  
> +/*
> + * Normalizes partial refs to their full qualified form.

s/full/&y/;

> + * If prefix is NULL, will prepend 'refs/' to the pattern if it doesn't start
> + * with 'refs/'. Results in refs/<pattern>
> + *
> + * If prefix is not NULL will result in <prefix>/<pattern>

s/NULL/&,/;

> + *
> + * If ENSURE_GLOB is set and no glob characters are found in the
> + * pattern, a trailing </><*> will be appended to the result.
> + * (<> characters to avoid breaking C comment syntax)
> + */
> +
> +#define ENSURE_GLOB 1
> +void normalize_glob_ref (struct strbuf *normalized_pattern, const char *prefix,
> +				const char *pattern, int flags);
> +
>  static inline const char *has_glob_specials(const char *pattern)
>  {
>  	return strpbrk(pattern, "?*[");

Thanks.  Other than the above minor points, looks good to me.

  reply	other threads:[~2017-11-04  2:27 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-11-04  0:41 [PATCH v1 0/2] Add option to git log to choose which refs receive decoration Rafael Ascensão
2017-11-04  0:41 ` [PATCH v1 1/2] refs: extract function to normalize partial refs Rafael Ascensão
2017-11-04  2:27   ` Junio C Hamano [this message]
2017-11-04  7:33     ` Rafael Ascensão
2017-11-04 22:45     ` Kevin Daudt
2017-11-05 13:21       ` Michael Haggerty
2017-11-05 13:42   ` Michael Haggerty
2017-11-06  1:23     ` Junio C Hamano
2017-11-06  2:37       ` Rafael Ascensão
2017-11-06  7:00       ` Michael Haggerty
2017-11-04  0:41 ` [PATCH v1 2/2] log: add option to choose which refs to decorate Rafael Ascensão
2017-11-04  3:49   ` Junio C Hamano
2017-11-04  7:34     ` Rafael Ascensão
2017-11-05  2:00       ` Junio C Hamano
2017-11-05  6:17         ` Junio C Hamano
2017-11-06  3:24           ` Rafael Ascensão
2017-11-06  3:51             ` Junio C Hamano
2017-11-06  7:09           ` Michael Haggerty
2017-11-06 20:10     ` Jacob Keller
2017-11-07  0:18       ` Junio C Hamano
2017-11-10 13:38         ` Rafael Ascensão
2017-11-10 17:42           ` Junio C Hamano
2017-11-21 21:33 ` [PATCH v2] " Rafael Ascensão
2017-11-22  4:18   ` Junio C Hamano

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=xmqqo9oiok10.fsf@gitster.mtv.corp.google.com \
    --to=gitster@pobox.com \
    --cc=git@vger.kernel.org \
    --cc=hjemli@gmail.com \
    --cc=ilari.liusvaara@elisanet.fi \
    --cc=me@ikke.info \
    --cc=mhagger@alum.mit.edu \
    --cc=pclouds@gmail.com \
    --cc=rafa.almas@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.