Build sequencing when using distributed version control

Question

Right now, we are using Perforce for version control. It has the handy feature of a strictly increasing change number that we can use to refer to builds, eg "you'll get the bugfix if your build is at least 44902".

I'd like to switch over to using a distributed system (probably git) to make it easier to branch and to work from home. (Both of which are perfectly possible with Perforce, but the git workflow has some advantages.) So although "tributary development" would be distributed and not refer to a common revision sequencing, we'd still maintain a master git repo that all changes would need to feed into before a build was created.

What's the best way to preserve strictly increasing build ids? The most straightforward way I can think of is to have some sort of post-commit hook that fires off whenever the master repo gets updated, and it registers (the hash of) the new tree object (or commit object? I'm new to git) with a centralized database that hands out ids. (I say "database", but I'd probably do it with git tags, and just look for the next available tag number or something. So the "database" would really be .git/refs/tags/build-id/.)

This is workable, but I'm wondering if there is an easier, or already-implemented, or standard/"best practice" way of accomplishing this.

Answer 1

Monotonically increasing number corresponding to the current commit could be generated with

git log --pretty=oneline | wc -l

which returns a single number. You can also append current sha1 to that number, to add uniqueness.

This approach is better than git describe, because it does not require you to add any tags, and it automatically handles merges.

It could have problems with rebasing, but rebasing is "dangerous" operation anyway.

Answer 2

I second the suggestion of using git describe. Provided that you have a sane versioning policy, and you don't do any crazy stuff with your repository, git describe will always be monotonic (at least as monotonic as you can be, when your revision history is a DAG instead of a tree) and unique.

A little demonstration:

git init
git commit --allow-empty -m'Commit One.'
git tag -a -m'Tag One.' 1.2.3
git describe    # => 1.2.3
git commit --allow-empty -m'Commit Two.'
git describe    # => 1.2.3-1-gaac161d
git commit --allow-empty -m'Commit Three.'
git describe    # => 1.2.3-2-g462715d
git tag -a -m'Tag Two.' 2.0.0
git describe    # => 2.0.0

The output of git describe consists of the following components:

1. The newest tag reachable from the commit you are asking to describe
2. The number of commits between the commit and the tag (if non-zero)
3. The (abbreviated) id of the commit (if #2 is non-zero)

#2 is what makes the output monotonic, #3 is what makes it unique. #2 and #3 are omitted, when the commit is the tag, making git describe also suitable for production releases.

Answer 3

    git rev-list BRANCHNAME --count

this is much less resource intensive than

    git log --pretty=oneline | wc -l