Re: [PATCH v3] git-branch: add support for --merged and --no-merged

[Junio C Hamano <gitster@pobox.com>]

Lars Hjemli <hjemli@gmail.com> 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.