From owner-freebsd-git@freebsd.org Sat Aug 29 10:56:25 2020 Return-Path: Delivered-To: freebsd-git@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 79B273D4CE2 for ; Sat, 29 Aug 2020 10:56:25 +0000 (UTC) (envelope-from samuelrp84@gmail.com) Received: from mail-vs1-xe44.google.com (mail-vs1-xe44.google.com [IPv6:2607:f8b0:4864:20::e44]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4BdtgX2nfDz4JWB for ; Sat, 29 Aug 2020 10:56:24 +0000 (UTC) (envelope-from samuelrp84@gmail.com) Received: by mail-vs1-xe44.google.com with SMTP id b16so938001vsl.6 for ; Sat, 29 Aug 2020 03:56:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=1UtXpzwAL/rH1usWBX9iw3lwfsbMItbkANo1S48DQuE=; b=Qs6aeEYd6zZCEUsLV3COSGFXq67hMR4LDsl8zOzO6EpKkc2zbOSDuDTrmxhBlH1FgN 2HIZCPYCiOsaF9bTFhzSECs3EwCq0f8BCRABkv2TjpfVTRIJEqR1VOYW4se+H3pf4mcd Tr7bJUG5XJPgiAoqtDLtKm5mwwXeym6MZjbhLvzdJpNywDXTn1M3ixpyaeVJZEyEpHEZ Ct34JlzSnoza+7TBAeClGdjSqx+K6IwpMrNeUp7qmayQ/+1dGfx3hhdw49K/3P10rupl qzyIzX2mLafnAGgH7bZxqXniZuNw+4uByODvDAoS1m0CDA5iv3LPcbIBkDOVBxCPa/Oo aKAw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=1UtXpzwAL/rH1usWBX9iw3lwfsbMItbkANo1S48DQuE=; b=aVWYZ+cpBUi2CI/qRzV5QLVMOzQi6F821uPCE+kwr9Ywv/ubHKJ7niopb0skAs3C3D m0LLXocdzCdZiKj0JTfikHcrHgVueFtD6COj7tenC4LU9Lds1zx9UlWcj0XHjdwadEcs nfpqMQIT3ldT03saR018UeSkZY8/4iZpBAlXxpArzekBmUZ+f6PRADAGozCG4db/ADAI XBtKaOV7B0EyfNi+yfSCLrvdcYT/PK2l6704mxltWiwLGwcLgE3sIGsdPVh6rh9mbJyx 7VI8XDy75QBQY0VZLkTyTSo25I5BafFmX5CBXfZwIwUGOqRWFo48CfHpkCK6aGj2Z+DV C13w== X-Gm-Message-State: AOAM530mZRY0zSFZeJrQ7P805n95uLS3lAksnXvV8uotKZIN3FM4+Uuk fUCUOicr7y2rVWtV98wBfB5JTDjx6hR/2FSYr3gs4U8BJ1Gq9g== X-Google-Smtp-Source: ABdhPJzfESAuIvzjktO1HdugL0H8vPrM7ulYdzQMecVwPuwyq+KBkyu1qwlRkxRnqmQf9aXEsKtAml36iLdQjzWFk0o= X-Received: by 2002:a05:6102:910:: with SMTP id x16mr1327569vsh.168.1598698582457; Sat, 29 Aug 2020 03:56:22 -0700 (PDT) MIME-Version: 1.0 From: =?UTF-8?Q?Samuel_Rodr=C3=ADguez?= Date: Sat, 29 Aug 2020 11:56:11 +0100 Message-ID: Subject: Re: SVN Revision-Like IDs in Git To: freebsd-git@freebsd.org X-Rspamd-Queue-Id: 4BdtgX2nfDz4JWB X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20161025 header.b=Qs6aeEYd; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of samuelrp84@gmail.com designates 2607:f8b0:4864:20::e44 as permitted sender) smtp.mailfrom=samuelrp84@gmail.com X-Spamd-Result: default: False [-1.53 / 15.00]; FREEMAIL_FROM(0.00)[gmail.com]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36]; TO_DN_NONE(0.00)[]; DKIM_TRACE(0.00)[gmail.com:+]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; NEURAL_HAM_SHORT(-0.22)[-0.218]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; R_MIXED_CHARSET(0.56)[subject]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim]; FAKE_REPLY(1.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20161025]; NEURAL_HAM_MEDIUM(-0.91)[-0.911]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-0.96)[-0.959]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-git@freebsd.org]; RCPT_COUNT_ONE(0.00)[1]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::e44:from]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[]; MAILMAN_DEST(0.00)[freebsd-git] Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.33 X-BeenThere: freebsd-git@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: Discussion of git use in the FreeBSD project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 29 Aug 2020 10:56:25 -0000 > On Thu, Aug 13, 2020 at 3:10 PM Sideropoulos, Alexander < > Alexander.Sideropoulos at 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 this > > will be provided and whether these will be available in the Git notes a= s > > they are now. > > > > So at least for our use-case at NetApp, it seems we should just bite th= e > > bullet and update our tooling to use Git commit hashes as input. > > > > But I cannot help but wonder... would it behoove FreeBSD to just provid= e > > 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? Haiku had gone through svn to git migration in 2011 and the approach the project had taken was based on pushing tags named with a prefix and the svn revision number taken from git-svn-id label provided by git svn migration tool. The prefix is hrev or btrev for the haiku and builtools repositories respectively plus a extra text matching the branch name if applicable. The result can be seen in the URLs below: https://git.haiku-os.org/haiku/ https://git.haiku-os.org/buildtools/ Once the migration was effective, a post-receive git hook to handle the creation of new tags based on commits pushed to the central repository had been introduced. The creates incremental revision numbers with differen= t prefixes depending on branch names. https://github.com/haiku/infrastructure/blob/master/data/gerrit/hooks/recei= ve-notify.pl#L766 Other build system related scripts for versioning proposes are detailed below: https://git.haiku-os.org/haiku/tree/build/scripts/determine_haiku_revision https://git.haiku-os.org/haiku/tree/build/jam/FileRules Oliver Tappe gave a tech talk at BeGeistert 024 about the migration process= : https://www.youtube.com/watch?v=3DyPZDLNHf_70 https://www.youtube.com/watch?v=3DvxjZ--ne-zc https://www.youtube.com/watch?v=3D_XQmZ6o0y38 https://www.youtube.com/watch?v=3D_mPEMOdBmBA Hope it helps. > > Committing to this course of action commits to a global lock. Since git i= s > 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 o= f > date order. This will be especially interesting when multiple patches lan= d > 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" 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 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-revi= sion-hashes-I-want-revision-numbers > > > > > > > > ...there are no plans to provide an SVN-revision-like ID for Gi= t > > 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 las= t > > 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" > > > > Thanks, Samuel Rodr=C3=ADguez P=C3=A9rez