SVN Revision-Like IDs in Git

Dimitry Andric dim at
Fri Aug 7 13:22:41 UTC 2020

On 7 Aug 2020, at 03:26, Warner Losh <imp at> wrote:
> On Thu, Aug 6, 2020, 4:01 PM Sideropoulos, Alexander <
> Alexander.Sideropoulos at> wrote:
>> Hey folks,
>> According to this page...
>> ...there are no plans to provide an SVN-revision-like ID for Git commits
>> once the switch-over happens.
>> At NetApp, we rely on the SVN revision number to uniquely identify our
>> FreeBSD baseline and every cherry-picked patch we apply on top of it. We
>> could update all our tooling to accept Git hashes, but this is not a small
>> task. And I imagine we are not the only downstream project reliant upon SVN
>> revision numbers.
>> Since the SVN revision ID is really just an arbitrary number, has there
>> been any thought in simply continuing to manufacture these numbers for Git
>> commits going forward? It could even be a post-commit operation where the
>> Git notes are updated with a unique (increasing) ID, just as is done today.
>> Thoughts?
> Git has the ability to generate a number of commits since the last tag (or
> maybe arbitrary tag). That is appropriately the same thing if you don't
> need temporal stability between branches...

A similar discussion has also taken place in the past when the LLVM
project was planning to migrate from Subversion to Git (and then to
GitHub). The gist was mostly written down here:

In short, if you forbid merge commits (either by policy or some server
side hook), you can have a semi-linear history, at least per branch.

Then you can use e.g. git describe output, or count the number of
commits since a particular starting point in the branch.


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 223 bytes
Desc: Message signed with OpenPGP
URL: <>

More information about the freebsd-git mailing list