SVN Revision-Like IDs in Git

Warner Losh imp at
Thu Aug 13 21:53:43 UTC 2020

On Thu, Aug 13, 2020 at 3:10 PM Sideropoulos, Alexander <
Alexander.Sideropoulos at> wrote:

> Thanks for the details, everyone. What I am gathering...
> 1) It is definitely possible for downstream projects (like NetApp) to
> generate an SVN revision-like ID with a one-to-one mapping of Git commits
> on a single branch. Care must be taken to use the same flags every time
> when "looking up" this number (e.g. to account for merge commits, etc.).
> 2) There are no plans for the FreeBSD project to provide generation
> numbers across all branches nor within a single branch. There are some
> plans for temporary SVN replication, though it is unclear for how long this
> will be provided and whether these will be available in the Git notes as
> they are now.
> So at least for our use-case at NetApp, it seems we should just bite the
> bullet and update our tooling to use Git commit hashes as input.
> But I cannot help but wonder... would it behoove FreeBSD to just provide
> these generation numbers as a service to all downstream projects?

We're looking at ways to provide this for current branches (11, 12).
There's a number of ways to do this, including continuing to publish this
data via subversion. We've heard from others as well expressing concern
around this part of the plan.

> Setting up a post-commit hook which generates this number and updates the
> commit notes would solve this problem for everyone, including FreeBSD's own
> release process. More so, this process could easily ensure the numbers are
> unique (and time-ordered) across branches, even continuing the sequence
> from the last SVN ID. Is that not desirable?

What other open source projects do this in the git world?

Committing to this course of action commits to a global lock. Since git is
distributed, you often have slight temporal distortions in the commit
sequences. git makes no date ordering guarantees. Without a date order,
having a serial number assigned per commit will also necessarily be out of
date order. This will be especially interesting when multiple patches land
all at once for things like security advisories that may have been done
days or weeks in the past prior to their being pushed due to embargo

I'm not forestalling this possibility, but anything we come up with will be
an imperfect FreeBSD-only solution.  Depending on how that's done, one that
we may have difficulty transporting to different 3rd parties and/or other
services that we'd like to roll out in the future (or maybe not, without
seeing any plan, it's hard to say one way or the other).


> --ap
> On 8/9/20, 14:29, "Ed Maste" <emaste at> wrote:
>     NetApp Security WARNING: This is an external email. Do not click links
> or open attachments unless you recognize the sender and know the content is
> safe.
>     On Thu, 6 Aug 2020 at 21:27, 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...
>     Git has a "generation number" that could be used for this purpose, but
>     unfortunately it isn't exposed in a user-facing way. It is possible to
>     count the number of commits from the root to the current head though,
>     and we include this number in the uname if build from git today. It
>     appears as a "-cXXXXXX" suffix. As long as you are tracking or
>     comparing only within a branch (e.g. stable/12) as Warner says it can
>     be used equivalently.
>     In sys/conf/ have a look at the block following the "if [ -n
>     "$git_cmd" ] ; then"

More information about the freebsd-git mailing list