All of lore.kernel.org
 help / color / mirror / Atom feed
From: Karthik Nayak <karthik.188@gmail.com>
To: Matthieu Moy <Matthieu.Moy@grenoble-inp.fr>
Cc: git@vger.kernel.org, christian.couder@gmail.com
Subject: Re: [PATCH 2/4] ref-filter: add ref-filter API
Date: Sat, 23 May 2015 23:22:51 +0530	[thread overview]
Message-ID: <5560BE73.8020801@gmail.com> (raw)
In-Reply-To: <vpq8ucffj8h.fsf@anie.imag.fr>

>
> But it also contains struct ref_filter_item **items, which as I
> understand it contains a list of refs (with name, sha1 & such).
>
> That's the part I do not find natural: the same structure contains both
> the list of refs and the way it should be filtered.
>
> Re-reading the patch, I seem to understand that you're putting both on
> the same struct because of the API of for_each_ref() which takes one
> 'data' pointer to be casted, so you want both the input (filter
> description) and the output (list of refs after filtering) to be
> contained in the same struct.

Was kinda confused, This clears out things, Thanks.

>
> But I think this could be clearer in the code (and/or comment + commit
> message). Perhaps stg like:
>
> struct ref_filter_data /* Probably not the best name */ {
>          struct ref_list list;
>          struct ref_filter filter;
> };
>
> struct ref_list {
>   	int count, alloc;
>   	struct ref_filter_item **items;
>   	const char **name_patterns;
> };
>
> struct ref_filter {
> 	const char **name_patterns;
> 	/* There will be more here later */
> };
>

This seems cleaner, agreed.

 >
 > I agree that it might be clearer to separate both. In this case
 > instead of "ref_list" the struct might be called "ref_filter_array" as
 > we already have "argv_array" in argv-array.h and "sha1_array" in
 > "sha1-array.h".
 >

Somehow ref_list seems more real to me, list of refs.

 >
 > And I do not think an array of things that are operated on should
 > not be named "ref_filter_item".
 >
 > Surely, the latter "set of operations to be applied" may currently
 > be only filtering, but who says it has to stay that way?  "I have a
 > set of refs that represent my local branches I am interested
 > in. Please map them to their corresponding @{upstream}" is a
 > reasonable request once you have an infrastructure to represent "set
 > of refs to be worked on" and "set of operations to apply", and at
 > that point, the items are no longer filter-items (map-items?).
 >

That's also a good point to consider, I shall rename and restructure the 
code as discussed here, thanks.

-- 
Regards,
Karthik

  parent reply	other threads:[~2015-05-23 17:53 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-05-20 13:14 [WIP] [PATCH 0/4] Unifying git branch -l, git tag -l, and git for-each-ref karthik nayak
2015-05-20 13:18 ` [PATCH 1/4] for-each-ref: rename refinfo members to match similar structures Karthik Nayak
2015-05-20 16:57   ` Matthieu Moy
2015-05-21  6:27     ` karthik nayak
2015-05-20 13:18 ` [PATCH 2/4] ref-filter: add ref-filter API Karthik Nayak
2015-05-20 19:07   ` Eric Sunshine
2015-05-21 17:30     ` karthik nayak
2015-05-21 18:40       ` Eric Sunshine
2015-05-22 12:30         ` karthik nayak
2015-05-21  8:47   ` Matthieu Moy
2015-05-21 17:22     ` karthik nayak
2015-05-21 17:59     ` karthik nayak
2015-05-22  6:44       ` Matthieu Moy
2015-05-22 12:46         ` karthik nayak
2015-05-23 14:42           ` Matthieu Moy
2015-05-23 16:04             ` Christian Couder
2015-05-23 17:00               ` Matthieu Moy
2015-05-23 17:18             ` Junio C Hamano
2015-05-23 22:33               ` Matthieu Moy
2015-05-23 17:52             ` Karthik Nayak [this message]
2015-05-20 13:18 ` [PATCH 3/4] for-each-ref: convert to ref-filter Karthik Nayak
2015-05-20 23:50   ` Junio C Hamano
2015-05-21  6:51     ` karthik nayak
2015-05-20 13:18 ` [PATCH 4/4] ref-filter: move formatting/sorting options from 'for-each-ref' Karthik Nayak

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=5560BE73.8020801@gmail.com \
    --to=karthik.188@gmail.com \
    --cc=Matthieu.Moy@grenoble-inp.fr \
    --cc=christian.couder@gmail.com \
    --cc=git@vger.kernel.org \
    /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.