tags:

views:

148

answers:

1

I've been using git for some time now and understand how commits work, tags, etc. I really like the ability to see incremented revision numbers after using git tag -a 1.0.0, but there's issues with that:

  • It tags everything, so any future work that shares that tag in history will reflect the tag, unless re-tagged.
  • It's a bit more work than I want to tag a commit as a release point, and then create a new branch for maintenance.

My goals are the following:

  • Develop product. Create branches for each stable version for maintenance-only work to be done for minor releases.
  • Not use tags/ git describe for the incremented number because of the above.
  • Still have some way to automatically set a build number, version number, ANYTHING that is human-friendly.

My biggest issue is that when pushing code to a server, the SHA1 commit ID doesn't give the user any indication of chronological order. I'm open to using a third party tool that could possible count the number of revisions in the branch, or something.

Any ideas?

+2  A: 

git describe creates a friendly (ish) name for a commit.

It concatenates the name of the nearest tagged parent of the given commit with the number of commits since the tag and an abbreviation of the sha1 used. This means that it is unique to a commit but also gives a good indication of what the commit was based on and how much has been committed since that tag.

Obviously, with the possibility of multiple branches in multiple places built on the same tag, just the number of commits since the tag won't necessarily describe a unique commit.

Charles Bailey
Example output: `v1.6.5-rc2-8-g2cc6859` (which means 8 commits after commit tagged `v1.6.5-rc2`; current commit has `2cc6859` as shortened SHA-1 id).
Jakub Narębski