Re: [PATCH v6 06/11] ref-filter: implement '--merged' and '--no-merged' options

[Karthik Nayak <karthik.188@gmail.com>]

On Mon, Jun 29, 2015 at 11:33 PM, Junio C Hamano <gitster@pobox.com> wrote:
> Karthik Nayak <karthik.188@gmail.com> writes:
>
>> +static void do_merge_filter(struct ref_filter_cbdata *ref_cbdata)
>> +{
>> +     struct rev_info revs;
>> +     int i, old_nr;
>> +     struct ref_filter *filter = ref_cbdata->filter;
>> +     struct ref_array *array = ref_cbdata->array;
>> +     struct commit **to_clear = xcalloc(sizeof(struct commit *), array->nr);
>> +
>> +     init_revisions(&revs, NULL);
>> +
>> +     for (i = 0; i < array->nr; i++) {
>> +             struct ref_array_item *item = array->items[i];
>> +             add_pending_object(&revs, &item->commit->object, item->refname);
>> +             to_clear[i] = item->commit;
>> +     }
>> +
>> +     filter->merge_commit->object.flags |= UNINTERESTING;
>> +     add_pending_object(&revs, &filter->merge_commit->object, "");
>> +
>> +     revs.limited = 1;
>> +     if (prepare_revision_walk(&revs))
>> +             die(_("revision walk setup failed"));
>> +
>> +     old_nr = array->nr;
>> +     array->nr = 0;
>> +
>> +     for (i = 0; i < old_nr; i++) {
>> +             struct ref_array_item *item = array->items[i];
>> +             struct commit *commit = item->commit;
>> +
>> +             int is_merged = !!(commit->object.flags & UNINTERESTING);
>> +
>> +             if (is_merged == (filter->merge == REF_FILTER_MERGED_INCLUDE))
>> +                     array->items[array->nr++] = array->items[i];
>> +             else
>> +                     free_array_item(item);
>> +     }
>> +
>> +     for (i = 0; i < old_nr; i++)
>> +             clear_commit_marks(to_clear[i], ALL_REV_FLAGS);
>> +     clear_commit_marks(filter->merge_commit, ALL_REV_FLAGS);
>> +     free(to_clear);
>> +}
>
> Did this come from somewhere else (e.g. tag -l or branch -l)?  If
> so, you'd need a note similar to what you added in [02/11] to the
> original.
>

Will do this, thanks.

> I also have a feeling that compared to an implementation based on
> paint_down_to_common(), including is_descendant_of(), this may be
> less precise (e.g. it would be confused with clock skew that lasts
> more than SLOP commits).  If we are inventing a new helper (as
> opposed to moving an existing one), we'd probably be better off
> doing a thin wrapper around paint_down_to_common() than calling
> revision-walk machinery.
>

I'll have a look and get back to you.

-- 
Regards,
Karthik Nayak