Date: Thu, 13 Aug 2020 15:53:29 -0600 From: Warner Losh <imp@bsdimp.com> To: "Sideropoulos, Alexander" <Alexander.Sideropoulos@netapp.com> Cc: Ed Maste <emaste@freebsd.org>, "freebsd-git@freebsd.org" <freebsd-git@freebsd.org>, "Maxwell, Larus" <Larus.Maxwell@netapp.com> Subject: Re: SVN Revision-Like IDs in Git Message-ID: <CANCZdfpqHXgUdWDn5=ZDG6=2T=q72re0-kCwmfPjOKOgAZtVgQ@mail.gmail.com> In-Reply-To: <8A974E48-CCC1-4E54-8E1D-C8A78149C5AB@netapp.com> References: <013F16E7-DDBB-4C2F-829D-D08B53CC7585@netapp.com> <CANCZdfoh85FWJ5wfkDAZzxKwcAwTTy7Dht4BUHJ=JT_L7pDH8g@mail.gmail.com> <CAPyFy2BjOn32iDyNR0mpuPz7Q4BRFAy2bzW4z-ez7qxEE46uTA@mail.gmail.com> <8A974E48-CCC1-4E54-8E1D-C8A78149C5AB@netapp.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, Aug 13, 2020 at 3:10 PM Sideropoulos, Alexander < Alexander.Sideropoulos@netapp.com> 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 th= is > 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 o= wn > release process. More so, this process could easily ensure the numbers ar= e > 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 reasons. 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). Warner > --ap > > =EF=BB=BFOn 8/9/20, 14:29, "Ed Maste" <emaste@freebsd.org> wrote: > > NetApp Security WARNING: This is an external email. Do not click link= s > 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@bsdimp.com> wrote: > > > > On Thu, Aug 6, 2020, 4:01 PM Sideropoulos, Alexander < > > Alexander.Sideropoulos@netapp.com> wrote: > > > > > Hey folks, > > > > > > According to this page... > > > > > > > https://hackmd.io/_lvyl1CfTsayB3L0v4fmLA#What%E2%80%99s-with-the-funny-re= vision-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 identif= y > 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 no= t > a small > > > task. And I imagine we are not the only downstream project relian= t > 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 number= s > 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, bu= t > unfortunately it isn't exposed in a user-facing way. It is possible t= o > 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" > >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CANCZdfpqHXgUdWDn5=ZDG6=2T=q72re0-kCwmfPjOKOgAZtVgQ>