How to sort git tags by version string order of form rc-X.Y.Z.W?

Use version sort

git tag -l | sort -V

or for git version >= 2.0

git tag -l --sort=v:refname
git tag -l --sort=-v:refname # reverse

With Git 2.0 (June 2014), you will be able to specify a sorting order!

See commit b6de0c6, from commit 9ef176b, authored by Nguyễn Thái Ngọc Duy (pclouds):

 --sort=<type>

Sort in a specific order.
Supported type is:

  • "refname" (lexicographic order),
  • "version:refname" or "v:refname" (tag names are treated as versions).

Prepend "-" to reverse sort order.

So, if you have:

git tag foo1.3 &&
git tag foo1.6 &&
git tag foo1.10

Here is what you would get:

# lexical sort
git tag -l --sort=refname "foo*"
foo1.10
foo1.3
foo1.6

# version sort
git tag -l --sort=version:refname "foo*"
foo1.3
foo1.6
foo1.10

# reverse version sort
git tag -l --sort=-version:refname "foo*"
foo1.10
foo1.6
foo1.3

# reverse lexical sort
git tag -l --sort=-refname "foo*"
foo1.6
foo1.3
foo1.10

Since commit b150794 (by Jacob Keller, git 2.1.0, August 2014), you can specific that default order:

tag.sort

This variable controls the sort ordering of tags when displayed by git-tag.
Without the "--sort=<value>" option provided, the value of this variable will be used as the default.

robinst comments:

the version sort order can now (Git 2.1+) be configured as default: 

git config --global tag.sort version:refname

As noted by Leo Galleguillos in the comments:

To configure Git to show newest tags first (descending order), just add a hyphen before version.
The command becomes: 

git config --global tag.sort -version:refname

With Git 2.4 (Q2 2015), the versionsort.prerelease configuration variable can be used to specify that v1.0-pre1 comes before v1.0.

See commit f57610a by Junio C Hamano (gitster).

Note (see below) versionsort.prereleaseSuffix is now (2017) a deprecated alias for versionsort.suffix.

git 2.7.1 (February 2016) will improve the output of git tag itself.

See commit 0571979 (26 Jan 2016), and commit 1d094db (24 Jan 2016) by Jeff King (peff).
(Merged by Junio C Hamano -- gitster -- in commit 8bad3de, 01 Feb 2016)

tag: do not show ambiguous tag names as "tags/foo"

Since b7cc53e (tag.c: use 'ref-filter' APIs, 2015-07-11), git tag has started showing tags with ambiguous names (i.e., when both "heads/foo" and "tags/foo" exists) as "tags/foo" instead of just "foo".
This is both:

  • pointless; the output of "git tag" includes only refs/tags, so we know that "foo" means the one in "refs/tags".
  • and ambiguous; in the original output, we know that the line "foo" means that "refs/tags/foo" exists. In the new output, it is unclear whether we mean "refs/tags/foo" or "refs/tags/tags/foo".

The reason this happens is that commit b7cc53e switched git tag to use ref-filter's "%(refname:short)" output formatting, which was adapted from for-each-ref. This more general code does not know that we care only about tags, and uses shorten_unambiguous_ref to get the short-name.
We need to tell it that we care only about "refs/tags/", and it should shorten with respect to that value.

let's add a new modifier to the formatting language, "strip", to remove a specific set of prefix components.
This fixes "git tag", and lets users invoke the same behavior from their own custom formats (for "tag" or "for-each-ref") while leaving ":short" with its same consistent meaning in all places.

If strip=<N> is appended, strips <N> slash-separated path components from the front of the refname (e.g., %(refname:strip=2) turns refs/tags/foo into foo.
<N> must be a positive integer.
If a displayed ref has fewer components than <N>, the command aborts with an error.

For git tag, when unspecified, defaults to %(refname:strip=2).

Update Git 2.12 (Q1 2017)

See commit c026557, commit b178464, commit 51acfa9, commit b823166, commit 109064a, commit 0c1b487, commit 9ffda48, commit eba286e (08 Dec 2016) by SZEDER Gábor (szeder).
(Merged by Junio C Hamano -- gitster -- in commit 1ac244d, 23 Jan 2017)

versionsort.prereleaseSuffix is a deprecated alias for versionsort.suffix.

The prereleaseSuffix feature of version comparison that is used in "git tag -l" did not correctly when two or more prereleases for the same release were present (e.g. when 2.0, 2.0-beta1, and 2.0-beta2 are there and the code needs to compare 2.0-beta1 and 2.0-beta2).


Combining the answers already here:

Local repository

git -c 'versionsort.suffix=-' tag --list --sort=-v:refname
  • suffix=- will prevent 2.0-rc coming "after" 2.0
  • --sort=- will put the highest version number at the top.

Remote repository

git -c 'versionsort.suffix=-' ls-remote -t --exit-code --refs --sort=-v:refname "$repo_url" \
    | sed -E 's/^[[:xdigit:]]+[[:space:]]+refs\/tags\/(.+)/\1/g'

The advantage of this is that no objects are downloaded from the remote.

For more info see this answer.

Tags:

Sorting

Git

Tags

Recent Posts