Re: [PATCH v7 01/12] for-each-ref: extract helper functions out of grab_single_ref()

2 messages, 2 authors, 2016-06-15 · open the first message on its own page

Re: [PATCH v7 01/12] for-each-ref: extract helper functions out of grab_single_ref()

From: Junio C Hamano <hidden>
Date: 2016-06-15 23:05:17

Karthik Nayak [off-list ref] writes:
quoted hunk
Extract two helper functions out of grab_single_ref(). Firstly,
new_refinfo() which is used to allocate memory for a new refinfo
structure and copy the objectname, refname and flag to it.
Secondly, match_name_as_path() which when given an array of patterns
and the refname checks if the refname matches any of the patterns
given while the pattern is a pathname, also supports wildcard
characters.

This is a preperatory patch for restructuring 'for-each-ref' and
eventually moving most of it to 'ref-filter' to provide the
functionality to similar commands via public API's.

Helped-by: Junio C Hamano [off-list ref]
Mentored-by: Christian Couder [off-list ref]
Mentored-by: Matthieu Moy [off-list ref]
Signed-off-by: Karthik Nayak <redacted>
---
 builtin/for-each-ref.c | 64 ++++++++++++++++++++++++++++++++------------------
 1 file changed, 41 insertions(+), 23 deletions(-)
diff --git a/builtin/for-each-ref.c b/builtin/for-each-ref.c
index f7e51a7..67c8b62 100644
--- a/builtin/for-each-ref.c
+++ b/builtin/for-each-ref.c
@@ -851,6 +851,44 @@ struct grab_ref_cbdata {
 };
 
 /*
+ * Return 1 if the refname matches with one of the patterns,
s/with //;
+ * otherwise 0.  The patterns can be literal prefix (e.g. a
+ * refname "refs/heads/master" matches a pattern "refs/heads/")
+ * or a wildcard (e.g. the same ref matches "refs/heads/m*",too).
+ */
I know this was my bad suggestion, but "refs/heads/m" can be thought
of as a "literal prefix" that may match "refs/heads/master"; we do
not want to make that match, so perhaps "literal" is a bad way to
say this.  "A pattern can be a path prefix or a worldcard"?

Re: [PATCH v7 01/12] for-each-ref: extract helper functions out of grab_single_ref()

From: Karthik Nayak <hidden>
Date: 2016-06-15 23:05:17

On 06/12/2015 11:00 PM, Junio C Hamano wrote:
Karthik Nayak [off-list ref] writes:
quoted
Extract two helper functions out of grab_single_ref(). Firstly,
new_refinfo() which is used to allocate memory for a new refinfo
structure and copy the objectname, refname and flag to it.
Secondly, match_name_as_path() which when given an array of patterns
and the refname checks if the refname matches any of the patterns
given while the pattern is a pathname, also supports wildcard
characters.

This is a preperatory patch for restructuring 'for-each-ref' and
eventually moving most of it to 'ref-filter' to provide the
functionality to similar commands via public API's.

Helped-by: Junio C Hamano [off-list ref]
Mentored-by: Christian Couder [off-list ref]
Mentored-by: Matthieu Moy [off-list ref]
Signed-off-by: Karthik Nayak <redacted>
---
  builtin/for-each-ref.c | 64 ++++++++++++++++++++++++++++++++------------------
  1 file changed, 41 insertions(+), 23 deletions(-)
diff --git a/builtin/for-each-ref.c b/builtin/for-each-ref.c
index f7e51a7..67c8b62 100644
--- a/builtin/for-each-ref.c
+++ b/builtin/for-each-ref.c
@@ -851,6 +851,44 @@ struct grab_ref_cbdata {
  };

  /*
+ * Return 1 if the refname matches with one of the patterns,
s/with //;
Thanks! will change :)
quoted
+ * otherwise 0.  The patterns can be literal prefix (e.g. a
+ * refname "refs/heads/master" matches a pattern "refs/heads/")
+ * or a wildcard (e.g. the same ref matches "refs/heads/m*",too).
+ */
I know this was my bad suggestion, but "refs/heads/m" can be thought
of as a "literal prefix" that may match "refs/heads/master"; we do
not want to make that match, so perhaps "literal" is a bad way to
say this.  "A pattern can be a path prefix or a worldcard"?
Yes! that sounds right, after all its doing a path match.

-- 
Regards,
Karthik
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help