Thread (31 messages) flat view 31 messages, 3 authors, 2016-06-15

Re: [PATCH v4 05/19] ref-filter: add parse_opt_merge_filter()

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

On Sun, Jun 21, 2015 at 1:48 PM, Karthik Nayak [off-list ref] wrote:
Add 'parse_opt_merge_filter()' to parse '--merged' and '--no-merged'
options and write MACROS for the same.
Why SHOUT here?
This is copied from 'builtin/branch.c' which will eventually be removed
when we port 'branch.c' to use ref-filter APIs.
Hmph. I somehow thought Matthieu's instruction was to finish tag.c
side first and then
do branch (i.e. with 3 and 4 you brought things from tag to
for-each-ref, now it is a time
to rewrite tag by using what you wrote for for-each-ref with 3 and 4,
before moving to
this patch)? Was that plan scrapped or found inappropriate or something?
+int parse_opt_merge_filter(const struct option *opt, const char *arg, int unset)
+{
+       struct ref_filter *rf = opt->value;
+       unsigned char sha1[20];
+
+       rf->merge = starts_with(opt->long_name, "no")
+               ? REF_FILTER_MERGED_OMIT
+               : REF_FILTER_MERGED_INCLUDE;
+
+       if (!arg)
+               arg = "HEAD";
When does this trigger? You have lastarg-default with "HEAD", and I am
having trouble guessing when "arg" upon entry to this function can ever
be NULL.
+       if (get_sha1(arg, sha1))
+               die(_("malformed object name %s"), arg);
+
+       rf->merge_commit = lookup_commit_reference_gently(sha1, 0);
Can --merged (or --no-merged) be given more than once? Is the rule
"the last one wins"?
Does the old value of rf->merge_commit leak (no, it does not, but I am
just asking for
completeness)?
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help