[PATCH 0/2] improve "git branch --contains=<commit> <pattern>"

From: Jeff King <peff@peff.net>
Date: Jan 31, 2013, 06:43 UTC
Message-ID: <20130131064357.GA24660@sigill.intra.peff.net>
In-Reply-To: <679787987.uZRbjA7AMj@al>

On Wed, Jan 30, 2013 at 07:57:03PM +0100, Peter Wu wrote:

Show 12 quoted lines

> Hi,
> 
> I was trying to check whether a certain branch contained a commit and ran:
> 
>      git branch --contains ddc150f7a33ae0c9cb16eaac3641abc00f56316f master
> 
> This resulted in:
> 
>     fatal: A branch named 'master' already exists.
> When "name" does not exist, this command creates a branch. I expect this 
> command to search the mentioned branch, not trying to create it. The manual 
> page of git-branch(1) does not mention such special behavior either.

Yeah, it's sort-of a bug. It is a syntactic ambiguity that an argument to git-branch could be a listing pattern or a new branch name. When using a listing pattern, you need to explicitly specify that you want list mode with `--list`. This is documented in git-branch under --list, but it should be more prominent, in the section that covers the various invocation modes. The first patch below fixes that.

That being said, we could be much more helpful. It seems like --contains should imply listing mode, since it is nonsensical in other modes. The second patch below adjusts that, and makes the command above do what you expect.

  [1/2]: docs: clarify git-branch --list behavior
  [2/2]: branch: let branch filters imply --list

-Peff