From: Junio C Hamano <gitster@pobox.com>
To: Karthik Nayak <karthik.188@gmail.com>
Cc: git@vger.kernel.org, christian.couder@gmail.com,
Matthieu.Moy@grenoble-inp.fr
Subject: Re: [PATCH v6 03/11] ref-filter: implement '--points-at' option
Date: Mon, 29 Jun 2015 10:40:18 -0700 [thread overview]
Message-ID: <xmqqmvzibegt.fsf@gitster.dls.corp.google.com> (raw)
In-Reply-To: <1435222633-32007-3-git-send-email-karthik.188@gmail.com> (Karthik Nayak's message of "Thu, 25 Jun 2015 14:27:05 +0530")
Karthik Nayak <karthik.188@gmail.com> writes:
> +/*
> + * Given a ref (sha1, refname) see if it points to one of the sha1s
> + * in a sha1_array.
> + */
> +static int match_points_at(struct sha1_array *points_at, const unsigned char *sha1,
> + const char *refname)
> +{
> + struct object *obj;
> +
> + if (!points_at || !points_at->nr)
> + return 1;
> +
> + if (sha1_array_lookup(points_at, sha1) >= 0)
> + return 1;
> +
> + obj = parse_object_or_die(sha1, refname);
> + if (obj->type == OBJ_TAG &&
> + sha1_array_lookup(points_at, ((struct tag *)obj)->tagged->sha1) >= 0)
> + return 1;
> +
> + return 0;
> +}
> +
Interesting. I think the change done while copying the code does
not change anything from the original (other than that the helper
lost its ability to return the peeled object name), and I think you
shouldn't make any change while copying the code that would change
the benaviour, but I notice a few things that we might want to keep
in mind and revisit them later (i.e. might be a good idea to add
NEEDSWORK comment to record them near the function):
- The original only peeled one level of indirection, so does this
implementation. But is that really what we want, I wonder?
After doing:
$ git tag -a -m 'annotated' atag $commit
$ git tag -a -m 'annotated doubly' dtag atag
atag^0, dtag^0 and $commit all refer to the same commit object.
Do we want to miss dtag with --point-at=$commit?
- As we are in for-each-ref (or eventually tag -l) that is walking
the cached refs, we may know what refname peels to without
parsing the object at all. Could it be more efficient to ask
peel_ref() for the pointee without doing parse_object()
ourselves?
next prev parent reply other threads:[~2015-06-29 17:40 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-06-25 8:46 [PATCH v6 00/11] add options to for-each-ref Karthik Nayak
2015-06-25 8:57 ` [PATCH v6 01/11] t6302: for-each-ref tests for ref-filter APIs Karthik Nayak
2015-06-25 8:57 ` [PATCH v6 02/11] tag: libify parse_opt_points_at() Karthik Nayak
2015-06-25 8:57 ` [PATCH v6 03/11] ref-filter: implement '--points-at' option Karthik Nayak
2015-06-29 17:40 ` Junio C Hamano [this message]
2015-06-29 19:37 ` Karthik Nayak
2015-06-25 8:57 ` [PATCH v6 04/11] for-each-ref: add " Karthik Nayak
2015-06-29 17:46 ` Junio C Hamano
2015-06-29 19:55 ` Karthik Nayak
2015-06-29 18:38 ` Junio C Hamano
2015-06-29 19:11 ` Karthik Nayak
2015-06-25 8:57 ` [PATCH v6 05/11] ref-filter: add parse_opt_merge_filter() Karthik Nayak
2015-06-25 8:57 ` [PATCH v6 06/11] ref-filter: implement '--merged' and '--no-merged' options Karthik Nayak
2015-06-29 18:03 ` Junio C Hamano
2015-06-29 18:28 ` Junio C Hamano
2015-06-30 13:38 ` Karthik Nayak
2015-06-30 15:58 ` Junio C Hamano
2015-06-30 16:04 ` Karthik Nayak
2015-06-25 8:57 ` [PATCH v6 07/11] for-each-ref: add " Karthik Nayak
2015-06-25 8:57 ` [PATCH v6 08/11] parse-option: rename parse_opt_with_commit() Karthik Nayak
2015-06-25 8:57 ` [PATCH v6 09/11] parse-options.h: add macros for '--contains' option Karthik Nayak
2015-06-25 8:57 ` [PATCH v6 10/11] ref-filter: implement " Karthik Nayak
2015-06-25 8:57 ` [PATCH v6 11/11] for-each-ref: add " Karthik Nayak
2015-06-29 18:14 ` [PATCH v6 01/11] t6302: for-each-ref tests for ref-filter APIs Junio C Hamano
2015-06-29 18:43 ` 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=xmqqmvzibegt.fsf@gitster.dls.corp.google.com \
--to=gitster@pobox.com \
--cc=Matthieu.Moy@grenoble-inp.fr \
--cc=christian.couder@gmail.com \
--cc=git@vger.kernel.org \
--cc=karthik.188@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.