SVN Revision-Like IDs in Git

[Sideropoulos, Alexander]

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?

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?

--ap

On 8/9/20, 14:29, "Ed Maste" <emaste at freebsd.org> 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 bsdimp.com> wrote:
    >
    > On Thu, Aug 6, 2020, 4:01 PM Sideropoulos, Alexander <
    > Alexander.Sideropoulos at netapp.com> wrote:
    >
    > > Hey folks,
    > >
    > > According to this page...
    > >
    > > https://hackmd.io/_lvyl1CfTsayB3L0v4fmLA#What%E2%80%99s-with-the-funny-revision-hashes-I-want-revision-numbers
    > >
    > > ...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/newvers.sh have a look at the block following the "if [ -n
    "$git_cmd" ] ; then"