"git branch --contains x y" creates a branch instead of checking containment

The "git branch --list --contains x y" command lists all branches that contains commit x and matches the pattern y. Reading the git-branch(1) manual page gives the impression that "--list" is redundant, and that you can instead write

   git branch --contains x y

That command does something completely different, though. The "--contains x" part is silently ignored, so it creates a branch named "y" pointing at HEAD.

Tested in git 1.8.1.1 and 1.8.1.4.

In my opinion, there are two ways to fix this:

- change the "git branch" implementation so that --contains implies --list.

- change the manual page synopsis so that
it is clear that --contains can only be used if --list is also used. Also add an error check to the "git branch" implementation so that using --contains without specifying --list produces a fatal error message.

Personally I would prefer the first solution.

Repeat by running these commands:

# Set up a repo with two commits.
# Branch a points to the oldest one, and

# b and master to the newest one.
mkdir contains || exit 1
cd contains
git init
touch a; git add a; git commit -m"Added a".
git branch a
touch b; git add b; git commit -m"Added b".
git branch b

git branch --list --contains a
# Prints "a", "b" and "master, as expected.

git branch --contains a
# Prints "a", "b" and "master, as expected.
# In this case, the --list option can be removed.

git branch --list --contains a b
# Prints "b", as expected. "b" is a <pattern>.

git branch --list --contains a c
# Prints nothing, as expected, as the "c" pattern doesn't match any of

# the existing branches.

git for-each-ref
# Prints three lines: refs/heads/a, refs/heads/b and # refs/heads/master, as expected.

git branch --contains a c
# Prints nothing, as expected, but...

git for-each-ref
# Prints four lines! Apparently, the command above created

# refs/heads/c.

/ceder

P.S. What I really wanted to do was "git merge-base --is-ancestor a b", but I keep forgetting its name.

I think that is the best option, too. In fact, I even wrote a patch. :)

It's d040350 (branch: let branch filters imply --list, 2013-01-31), and it's already in v1.8.2-rc0.

-Peff

Great! Thanks for the quick fix of my bug report. Negative response time... not bad. Not bad at all. :-)

/ceder

Yeah, Jeff has a time machine ;-)