-
-
Save rponte/fdc0724dd984088606b0 to your computer and use it in GitHub Desktop.
# The command finds the most recent tag that is reachable from a commit. | |
# If the tag points to the commit, then only the tag is shown. | |
# Otherwise, it suffixes the tag name with the number of additional commits on top of the tagged object | |
# and the abbreviated object name of the most recent commit. | |
git describe | |
# With --abbrev set to 0, the command can be used to find the closest tagname without any suffix: | |
git describe --abbrev=0 | |
# other examples | |
git describe --abbrev=0 --tags # gets tag from current branch | |
git describe --tags `git rev-list --tags --max-count=1` # gets tags across all branches, not just the current branch | |
@MarcusPetri found this on StackOverflow: https://stackoverflow.com/a/6270112/899075
git for-each-ref --sort=creatordate --format '%(refname) %(creatordate)' refs/tags
But are you interested in when the tag itself was actually created, or, are you really just interested in seeing the semantically largest tag number (see number sorting below)? The reason I ask is because it's technically possible for you to currently be on v2 but then at a later date create the tag v1.1 (which is obviously smaller) well after both v1 and v2 already existed. That command would sort it as v1, v2, v1.1 instead of the semantic ordering of v1, v1.1, v2 and etc.
Example of naïve sort vs. version sorting:
# Naïve sort $ sort test/test.txt 0 1.01 10.1 2
vs.
# Version sort $ sort -V test/test.txt 0 1.01 2 10.1
Thanks for the answer.
I just really need the last tag created, I don't care if it has v1, v2...
git tag | sort -g | tail -1
Get the latest tags filtered by branch in descending order, this one looks for latest tags in desc order from develop branch:
git tag --merged develop --sort=committerdate | sort -V desc
git ls-remote --tags --sort=committerdate
important: (from https://git-scm.com/docs/git-ls-remote.html)
_but be aware keys like committerdate that require access to the objects themselves will not work for refs whose objects have not yet been fetched from the remote, and will give a missing object error.
I get this for example on:
git ls-remote --tags --sort=committerdate "https://github.com/box/box-java-sdk"
git ls-remote --tags --sort=committerdate "https://github.com/derailed/k9s"
Get:
tilo@mypc:/mnt/c/GHreps$ git ls-remote --tags --sort=committerdate "https://github.com/derailed/k9s"
fatal: missing object 25b364dd96ae53e70b9639a20732647fd4bb23a7 for refs/tags/0.1.0
tilo@mypc:/mnt/c/GHreps$ git ls-remote --tags --sort=committerdate "https://github.com/box/box-java-sdk"
fatal: missing object 9a8b39475952def867a5b68ab92e7cd45bb3d8e0 for refs/tags/v0.1
If the remote is GitHub and there's an associated release for the tag, why not just use the GitHub API?
$ tag="$(curl -s https://api.github.com/repos/box/box-java-sdk/releases/latest | jq -r '.tag_name')"
$ echo $tag
v4.0.1
Just deleted a stupid long ass comment. Just want to warn about git tag --sort=committerdate
it does not work correctly with the tag command for whatever reason. But this does work.
git for-each-ref --sort=creatordate --format '%(refname) %(creatordate)' refs/tags
COMPLETELY different result that makes no sense to me git tag --sort=committerdate
However git tag --sort=taggerdate
is basically what I always looked for, what should be the default output for git-tag
IMG. I also hate how it paginates the output with less
or whatever by default.
Again, be warned about committerdate
! There is somebody above that had issue as well I think because of this. Even if my commit of things I tagged days or maybe even a week later. I makes absolutely no sense to me WTF this produces. Maybe my memory is just bad and it all makes sense, well probably actually. I think to much about this shit.
@eggbean I like that idea, but it hits an auth wall for private/enterprise repos
@arderyp There are a few different ways to authenticate. Have you tried the gh
cli tool?
Thanks! :)
@MarcusPetri found this on StackOverflow: https://stackoverflow.com/a/6270112/899075
But are you interested in when the tag itself was actually created, or, are you really just interested in seeing the semantically largest tag number (see number sorting below)? The reason I ask is because it's technically possible for you to currently be on v2 but then at a later date create the tag v1.1 (which is obviously smaller) well after both v1 and v2 already existed. That command would sort it as v1, v2, v1.1 instead of the semantic ordering of v1, v1.1, v2 and etc.
Example of naïve sort vs. version sorting:
# Naïve sort $ sort test/test.txt 0 1.01 10.1 2
vs.
# Version sort $ sort -V test/test.txt 0 1.01 2 10.1