On Fri, Mar 10, 2017 at 11:43:15AM +0100, Ævar Arnfjörð Bjarmason wrote:
> Ran into this when preparing my --no-contains series, this is a long > standing bug: > > $ ./git branch -D test; ./git branch --contains v2.8.0 test; echo > $?; git rev-parse test > error: branch 'test' not found. > 0 > test > fatal: ambiguous argument 'test': unknown revision or path not in > the working tree. Isn't that asking to list branches starting with "test" that contain v2.8.0? There are none to report (since you just made sure to delete it), so the empty output is correct. > I.e. this should return an error like "git tag" does: > > $ ./git tag -d test; ./git tag --contains v2.8.0 test; echo $?; > git rev-parse test > error: tag 'test' not found. > fatal: --contains option is only allowed with -l. > 128 > test > fatal: ambiguous argument 'test': unknown revision or path not in > the working tree. The difference between "branch" and "tag" here is that "branch --contains" implies "--list" (and the argument becomes a pattern). Whereas "tag --contains" just detects the situation and complains. If anything, I'd think we would consider teaching "tag" to behave more like "branch". -Peff
