"bob status" seems to get confused when different tags exist for the same commit

[aaronpohle]

Sometimes we have the case that different tags exist for the same commit.
"bob status" then shows the wrong status "S":

(recipes) $ bob status -v
   STATUS S    dev/src/foobar/1/workspace/foobar
   > tag: configured: 'foobar-3.13.1', actual: '3.13.1, barfoo-3.13.1'

(dev/src/foobar/1/workspace/foobar) $ git status
HEAD detached at foobar-3.13.1
nothing to commit, working tree clean

(dev/src/foobar/1/workspace/foobar) $ git log 
commit 41ddec19d6e3aefeec613fb53d7bca32136ca015 (HEAD, tag: foobar-3.13.1, tag: barfoo-3.13.1, tag: 3.13.1, origin/master)
[...]

(recipes) $ cat recipes/foobar.yaml 
[...]
checkoutSCM:
  - scm: git
[...]
    dir: foobar
    tag: foobar-3.13.1

Used version of bob: Bob version 0.22.1.dev35

[jkloetzke]

I could not reproduce the issue, even with old git versions. Bob simply calls git tag --points-at HEAD to get all tags that point at the currently checked out commit. Somehow not all tags are reported in your case.

The only way how I could provoke such a behaviour is when I create nested, annotated tags:

$ git tag -a foo HEAD
$ git tag -a nested foo
Hinweis: Sie haben einen verschachtelten Tag erzeugt. Das Objekt, auf welches Ihr
Hinweis: neues Tag referenziert, ist bereits ein Tag. Wenn Sie das Objekt taggen
Hinweis: wollten, worauf dieses zeigt, nutzen Sie:
Hinweis: 
Hinweis:        git tag -f nested foo^{}
$ git tag -l
foo
nested
$ git tag --points-at HEAD
foo

Could you check if the offending tag in your case is such a nested tag? Just do a git show <tag>. If you get two tags in the output then it is exactly this problem.

[aaronpohle]

The fix works! The output of "bob status" is now correct.

[jkloetzke]

Thanks for testing.