How to manage lots of git tags

I have lots of git tags in a repo that is used across several teams in our company. The net result of this is that trying to find a particular tag is quite cumbersome. What makes it worse is the fact tag sorting is broken (1.0.2 appears after 1.0.119).

 

Any suggestions on how to make these more manageable?

 

We use semantic versioning (MAJOR.MINOR.PATCH) so would it be possible to add a feature to collapse/expand a set of tags based on any/all of MAJOR/MINOR/PATCH number?

2 answers

1 accepted

0 votes
Accepted answer

Tags are sorted alphabetically. You COULD revise your naming convention to include leading zeroes, if you have some foresight into how many digits you are likely to use at a particular level (1.0.002 instead of 1.0.2).

Alternatively, just knowing that sorting is alphabetical makes it easy to find what you're looking for. 1.0.2 will come after 1.0.1, 1.0.1x, 1.0.1xx, 1.0.1xxxxx...

Someone else asked this question recently, and it was recommended that they prepend 'v' to their tag names (v1.0.119, v1.0.2). This is according to semantic versioning convention (http://stackoverflow.com/questions/2006265/is-there-a-standard-naming-convention-for-git-tags) but I don't know whether it will have any effect on how SourceTree sorts the tags (don't use semantic versioning myself).

Thanks for the prompt feedback. The format vX.Y.Z was SemVer 1.0.0, we use 2.0.0 where the 'v' has been dropped and leading zeros explicitly forbidden. This is just an incompatibility I suppose.

Fair enough. Like I said, I don't use it myself, just did some googling in response to your question, and based on a previous answer I'd read. I'd be curious whether SourceTree sorts tags using the SemVer 1.0.0 format more intelligently.

One issue to mention:

We once used CVS - with a looooot of tags. After converting the repositories to git we tried to push our local git repository to STASH/Bitbucket server using the http-protocol. This fails due to the limited length of contents of the http-protocol: not all the tags where pushed.

Switching to ssh-protocol allows pushing all the tags at once (another solution was multiple pushing the repos via http - on the subsequent pushes non previously pushed tags have been pushed - we avoided this method, cause we were sceptical whether all tags have been pushed ...)

So be aware, working with a huge amount of tags using the http-protocol to access remote repos might be problematic - you should consider using ssh in this case.

Thanks for the heads up Johannes. Luckily enough we already use SSH by default.

Suggest an answer

Log in or Sign up to answer
Community showcase
Published Oct 23, 2018 in Sourcetree

Tip from the team: configure your repos for hosting goodness!

Supported Platforms macOS Windows We recently introduced support for additional hosting services such as GitHub Enterprise, GitLab (Cloud, Community Edition, Enterprise Edition), and...

698 views 3 2
Read article

Atlassian User Groups

Connect with like-minded Atlassian users at free events near you!

Find a group

Connect with like-minded Atlassian users at free events near you!

Find my local user group

Unfortunately there are no AUG chapters near you at the moment.

Start an AUG

You're one step closer to meeting fellow Atlassian users at your local meet up. Learn more about AUGs

Groups near you