Simulating a global revision number with git

How would I go about simulating a global increasing revision number for every commit in the git main line?

So, after I commit I would like a script to run increases a number somewhere.

This will allow me to tell my customers easily that X feature was fixed in git revision XYZ.

I am looking for a practical sample script that is robust enough to handle pushes and merges to a degree.

From stackoverflow

• I think you're confusing revision numbers with release numbers.

  Subversion uses revision numbers because it can: it's a centralized repository. Git of course has SHA-1 hashes not revision numbers because it has no central repository (but you know this).

  That revision number (and the hash is technically a 160 bit number, it's just not sequential) shouldn't really be of concern to your customers. What they should be concerned with is the release number. That's when you package up your source code and say "this is version 2.3.4", complete with release notes to say what's changed.

  Ideally such a list is generated by issue-tracking software and your source code is simply tagged to say which revision constitutes that release number.

  Juliano : Except that Git doesn't use 128-bit GUIDs at all. Git uses 160-bit SHA-1 hashes of the each object stored. A GUID is a completely different beast: http://en.wikipedia.org/wiki/GUID

  cletus : Oh woops, thanks. Fixed.

• It's possible to simulate a revision number in git, however it's important to know that it's not a perfect match and not the easiest to trace back to. Personally I use it to make more simple revision numbers for a web app because I'm the sole developer. I use the following function in my .bashrc to get the revision number which I then use for the release notes (however if you aren't already I highly recommend tagging the release - then the number is just for users). If the limitations are well known it gives a much more human friendly revision number.

  function rgit() {
      git rev-list --abbrev-commit HEAD | wc -l | awk '{print $1}'
  }
  

  Sam Saffron : That is truely awesome, I have the exact same problem, single dev on a web app that is moving really quickly. I understand that this can go pear shape if I start re-writing history but accept that limitation.

• git describe gives you a version description like the following: v2.0-64-g835c907. The v2.0 part is the name of the latest annotated tag preceding the commit, 64 is the number of commits after that, and 835c907 is the abbreviated commit id. It is basically there to identify any revision in an exact and convenient (although technical) way.

  Note: For this to work you will need at least one annotated tag. To create one for version v2.0 run - git tag -a v2.0, if you have no annotated tags this command will fail, unless given a fallback argument like --tags or --always.

  Sam Saffron : I think I will accept this, it is the git-way and will be robust enough long term to handle multi dev scenarios ... I can always show the customers on the web site 2.0.64 and then keep the rest of the info on the file system somewhere so I can track the commit.

• I (being unaware of git describe) have been using the following script:

  #!/bin/bash
  
  FULL_BRANCH=`git branch | grep '*'`
  BRANCH_NAME=${FULL_BRANCH:2}
  REV=`git rev-parse --short HEAD`
  
  $COMMIT_NAME = $BRANCH_NAME-$REV
  

  This gives you a name that contains the current branch name, followed by the short commit ID. For example: master-c03f862.

  It is enough to do what you are after, but perhaps git describe is the correct way to go here.