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

When I enter a command:

git tag -l

I get such results:

rc-0.9.0.0
rc-0.9.0.1
rc-0.9.0.10
rc-0.9.0.11
rc-0.9.0.12
rc-0.9.0.2
rc-0.9.0.3
rc-0.9.0.4
rc-0.9.0.5
rc-0.9.0.6
rc-0.9.0.7
rc-0.9.0.8
rc-0.9.0.9

Instead of this I want:

rc-0.9.0.0
rc-0.9.0.1
rc-0.9.0.2
rc-0.9.0.3
rc-0.9.0.4
rc-0.9.0.5
rc-0.9.0.6
rc-0.9.0.7
rc-0.9.0.8
rc-0.9.0.9
rc-0.9.0.10
rc-0.9.0.11
rc-0.9.0.12

How it's possible to sort current list to get such results?

Solution 1:

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

Solution 2:

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).

Solution 3:

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.

Solution 4:

According to this answer, on platforms which don't support sort -V like Windows and OSX, you can use

git tag -l | sort -n -t. -k1,1 -k2,2 -k3,3 -k4,4

Solution 5:

To get a reverse sorting with the sort -V approach:

git tag -l | sort -V --reverse