search

stevemao / git-latest-semver-tag

Get the most recent git semver tag of your repository
7 stars 4 forks source link

Release v1.0.1 doesn't work with older version of `git` #3

Open cueedee opened 8 years ago

cueedee commented 8 years ago

Specifically, using git version 1.7.12.4 (Apple Git-37) , the output of:

git log --date-order --tags --simplify-by-decoration --pretty=format:"%d"

Doesn't include the tag: prefix for tagged commits. That is, for example it produces this:

 (HEAD, release/v1.0.1, develop)
 (origin/develop)
 (v1.0.0)

... instead of this:

 (HEAD -> release/v1.0.1, develop)
 (origin/develop)
 (tag: v1.0.0)

And that causes your regex to not match.

It looks like the next, as of yet unreleased version of index.js in master will already fix this. Is it going to be released anytime soon?

Alternatively you might consider changing index.js @ v1.0.1 from this:

var cmd = 'git log --date-order --tags --simplify-by-decoration --pretty=format:"%d"';

... into this:

var cmd = 'git log --date-order --tags --simplify-by-decoration --decorate --oneline --no-color';

... because that output does match.

cueedee commented 8 years ago

On closer inspection, v1.0.1 and the current master do not exhibit identical behaviour:

When the repository does contain semver tags, but not in the current branch, then the current master will not find it, but v1.0.1 (given a recent git) will.

o---o---o  tag:v1.0.0, master
      \
       o---o---o  HEAD, develop

This is because git-semver-tags (as used in the current master) walks only the current branch, whereas v1.0.1 includes all tags.

kachkaev commented 7 years ago

@cueedee have you been checking this issue more recently? Is is still the case that the tags from other branches are being grabbed?

cueedee commented 7 years ago

@kachkaev; I hadn't looked into this since reporting the issue, but I have now.

I find that the currrent git-latest-semver-tag(@v1.0.2) will not find the v1.0.0 tag in the above example.

The previous git-latest-semver-tag(@v1.0.1) otoh, does (or did) find it.

Note that this isn't the issue originally reported, but it would seem this is definitely a problem too if git-latest-semver-tag really is expected to find the latest semver-tag regardless of the currently checked out commit.