lerna version gets confused by non-lerna tags

Expected Behavior

• Given a repo that contains both lerna packages, and a non-lerna package with its own top-level subfolder and package.js
• The non-lerna package also creates git tags on new releases (the lerna package tags are prefixed with @my-group/ while the non-lerna tags are prefixed with legacy/)
• lerna version should ignore git tags of the non-lerna package and being able to find and tag changed packages independently of git tags of the non-lerna package

Current Behavior

When the latest tag on the master branch is from the non-lerna package, and after that no changes have been made to the lerna packages, lerna will output that there are no changes:

lerna info Looking for changed packages since legacy/0.35.3
lerna info No changed packages found

Possible Solution

Ignore tags that have a non-matching name.

Steps to Reproduce (for bugs)

1. Create a lerna repo with some packages and make a release
2. Make changes to the lerna packages and commit
3. Create a manual tag for the latest commit
4. Try to run lerna version and observe that it does not recognize the changes from 2.

lerna.json

{
  "packages": [
    "packages/*"
  ],
  "version": "independent"
}

Note that the non-lerna package is NOT contained in the packages/ folder.

Context

We introduced lerna later in our repository and created new separate published packages for the lerna packages, and use a starvation strategy for the old legacy package.

Your Environment

Executable	Version
lerna --version	3.19.0
npm --version	6.12.0
node --version	v12.13.0

OS	Version
macOS Catalina	10.15.1 (19B88)

[evocateur]

I still feel that the WIP branch provides important functionality, but I can’t give any timeline on completion. Using lightweight tags for the “external” tags (instead of annotated tags) is the best workaround I can think of, right now.

[evocateur]

So I fixed the bad tests inmaster, but wasn’t able to get to a complete solution on the tag filtering. I agree that it’s valuable to have, but as I indicated in the commit that references this issue, I still haven’t addressed the collectUpdates() usage here: https://github.com/lerna/lerna/blob/167d6e3abd81af1f8bed587f649b93016c76dc20/core/filter-options/lib/get-filtered-packages.js#L60

Without filtering that execution, almost any command outside of lerna publish/lerna version in a repo where external annotated git tags exist would likely be incorrect. Additional tests are needed to guard against regression, too.