On Wed, Jan 30, 2013 at 07:57:03PM +0100, Peter Wu wrote:
> 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
[1/2]: docs: clarify git-branch --list behavior
[2/2]: branch: let branch filters imply --list
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html