Lars Hjemli <hjemli@xxxxxxxxx> writes:
> Junio C Hamano wrote:
>> If the existing --contains implemenation can be extended to allow negative
>> selection, we do not have to introduce yet another mechanism that is very
>> similar.
>
> Very true, so here's an updated version which reuses has_commit(). Thanks
> for the feedback.
> + if (mergefilter > -1) {
> + branch.item = lookup_commit_reference_gently(sha1, 1);
> + if (!branch.item)
> + die("Unable to lookup HEAD of branch %s", refname);
> + if (mergefilter == 0 && has_commit(head_sha1, &branch))
> + return 0;
> + if (mergefilter == 1 && !has_commit(head_sha1, &branch))
> + return 0;
> + }
You did not answer my question as to how --contains and --merged relate to
each other. I'll answer it myself (please add a documentation updates, as
this would be confusing). The output from the former is "branches I need
to be careful about, if I were to rewind and rebuild this branch" (that is
what I invented the option for). The output from the latter is "branches
I can remove with 'git branch -d'".
* --contains (aka with_commit) gets a single commit; only the branches
that are descendant of that named commit will be shown (iow, these
branches contain the commit), with the expression:
/* Filter with with_commit if specified */
if (!has_commit(sha1, ref_list->with_commit))
return 0;
where "sha1" is the commit at the tip of the branch in question in this
round of the loop.
* --merged is the opposite way. Only the branches whose tips are
ancestors of the HEAD will be shown (iow, the HEAD contains these
branches), with the expression:
if (has_commit(head_sha1, &branch))
where "head_sha1" is the HEAD, and "branch" is the branch in question
in this round of the loop. i.e. it asks the same question as
--contains but in the opposite way.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
