Will there ever be a case where the output of git rev-list --all --count will go down if executed at a later date, from any branch of the same repository?
(I want to use it as a build number that will monotonically increase across all branches.)
Can "git rev-list --all --count" ever go down?
Viewed 1812
2 Answers
The accepted answer is incomplete; it doesn't account for grafts, replacement objects, or shallow clones. Consider the following example, where a 10-commit history only looks like a 3-commit history when it's cloned using --depth 3:
$ git init temp
Initialized empty Git repository in /rnsdhpc/code/src/temp/.git/
$ cd temp
$ for i in $(jot 10); do git commit -m "dummy commit $i" --allow-empty; done
[master (root-commit) 32cc222] dummy commit 1
[master a9c1d91] dummy commit 2
[master 3ab734f] dummy commit 3
[master 1d7c4f8] dummy commit 4
[master 74c6116] dummy commit 5
[master 447d696] dummy commit 6
[master a9cf900] dummy commit 7
[master 7cc0a16] dummy commit 8
[master 6a43b81] dummy commit 9
[master 4dbcdc0] dummy commit 10
$ git rev-list --all --count
10
$ cd ..
$ git clone --depth 3 file://$PWD/temp temp2
Cloning into 'temp2'...
remote: Enumerating objects: 4, done.
remote: Counting objects: 100% (4/4), done.
remote: Compressing objects: 100% (3/3), done.
remote: Total 4 (delta 2), reused 0 (delta 0)
Receiving objects: 100% (4/4), done.
Resolving deltas: 100% (2/2), done.
$ cd temp2
$ git rev-list --all --count
3
$ git log --oneline -3
4dbcdc0 (HEAD -> master, origin/master, origin/HEAD) dummy commit 10
6a43b81 dummy commit 9
7cc0a16 (grafted) dummy commit 8
I've encountered this unexpected behavior when using the Spack package manager to install my software, which uses git --no-replace-objects rev-list --count to save a revision number. Alas, the revision number always appears as 1 because Spack uses a shallow clone.
Related