From nobody Mon Jun 7 22:29:51 2021 X-Original-To: freebsd-git@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 1E08514CFE84 for ; Mon, 7 Jun 2021 22:30:03 +0000 (UTC) (envelope-from lwhsu@freebsd.org) Received: from smtp.freebsd.org (smtp.freebsd.org [IPv6:2610:1c1:1:606c::24b:4]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4FzSjl0968z4hpt; Mon, 7 Jun 2021 22:30:03 +0000 (UTC) (envelope-from lwhsu@freebsd.org) Received: from mail-yb1-f170.google.com (mail-yb1-f170.google.com [209.85.219.170]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) (Authenticated sender: lwhsu/mail) by smtp.freebsd.org (Postfix) with ESMTPSA id DD1A67F2; Mon, 7 Jun 2021 22:30:02 +0000 (UTC) (envelope-from lwhsu@freebsd.org) Received: by mail-yb1-f170.google.com with SMTP id m9so20818247ybo.5; Mon, 07 Jun 2021 15:30:02 -0700 (PDT) X-Gm-Message-State: AOAM532q2XX3ZOPfdQUPKjypmP0MwlhPyjGMvMWF0qMMvJmICj6rx4ZD wMv9XtOkpoCmcDvie7L2NEEJThyDL1bQEzPvxg4= X-Google-Smtp-Source: ABdhPJz+OAfeBqldNx67Ps+XHLvt+UrQcm9jhVuTlnKpErDVELTAYkP6cwmc5TOuF1mUbvEURrOQDhzC9cF49KiIIOI= X-Received: by 2002:a25:8191:: with SMTP id p17mr27325125ybk.405.1623105002446; Mon, 07 Jun 2021 15:30:02 -0700 (PDT) List-Id: Discussion of git use in the FreeBSD project List-Archive: https://lists.freebsd.org/archives/freebsd-git List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-git@freebsd.org MIME-Version: 1.0 References: In-Reply-To: From: Li-Wen Hsu Date: Tue, 8 Jun 2021 06:29:51 +0800 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: OpenZFS imports, status update To: freebsd-git Cc: Martin Matuska , =?UTF-8?Q?Ulrich_Sp=C3=B6rlein?= , Warner Losh , Xin LI Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-ThisMailContainsUnwantedMimeParts: N After some discussion and experiments. Following are the current status and the planned route: Currently the staging git repository has been updated: https://cgit-dev.freebsd.org/src/ See the merge commits in main and stable/13 branches, and now we have three branches under vendor/openzfs/: - vendor/openzfs/master (imported from upstream openzfs/master, will be merged to main) - vendor/openzfs/zfs-2.1-release (imported from upstream openzfs/zfs-2.1-release, will be merged to stabe/13) - vendor/openzfs/legacy (renamed from the old vendor/openzfs) To Ulrich: the plan is importing openzfs branches as-is (same hash values) to the vendor/openzfs so the history of the old vendor/openzfs can not be shared. We have modified the commit hooks to: 1. Allow vendor/openzfs/* branches import commits from committer with address not @FreeBSD.org 2. Allow merge from vendor/openzfs/zfs-2.1-release to stable/13 3. The commit mail generated for the vendor branch will be "one mail per push", not having the complete diff but a list of commits' short hash and subject line. And to allow creating master and zfs-2.1-release branches in the vendor/openzfs namespace, we need to rename the original vendor/openzfs to create rooms for them. Because we disallow deleting branches or other destructive operations from remote and it's not that cost-effective to modify the configuration and hooks for this single operation. I would like to just rename the branch on the server, with command: git branch -m vendor/openzfs vendor/openzfs/legacy The people have local branch tracking the original vendor/openzfs will encounter issues like this whey doing `git pull`: error: cannot lock ref 'refs/remotes/freebsd/vendor/openzfs/legacy': 'refs/remotes/freebsd/vendor/openzfs' exists; cannot create 'refs/remotes/freebsd/vendor/openzfs/legacy' The solution is update the upstream of the tracking branch: (change "freebsd" to "origin" if you use default remote name) git update-ref -d refs/remotes/freebsd/vendor/openzfs git branch -u freebsd/vendor/openzfs/legacy vendor/openzfs/legacy I will send an announcement for this operation and migration tip to -git and other related lists. Please let me know if there is anything I missed. If it sounds good, I will deploy the configurations and hooks to the production git repository and let Martin be able to import the new OpenZFS codes soon. Best, Li-wen On Sat, Apr 24, 2021 at 4:24 AM Ulrich Sp=C3=B6rlein wrot= e: > > Wouldn't vendor/openzfs/master simply be an alias for openzfs/master and > it would be the pristine upstream source repo? Or do we have local > modifications in our vendor/openzfs/master, if so, ignore me. > > On Fri, 2021-04-23 at 02:50:57 +0200, Martin Matuska wrote: > >Hi Warner, > > > >thank you very much for the update. > > > >If I understand this correctly, the way to go in the future is a 1:1 > >merge from openzfs/master to e.g. vendor/openzfs/master and from > >openzfs/zfs-2.1-release to vendor/openzfs/zfs-2.1-release? And as a > >second step a subtree merge from vendor/openzfs/* to main or stable/13? > > > >Martin > > > >On 22. 4. 2021 20:34, Warner Losh wrote: > >> Hey Martin, > >> > >> I just wanted to let you know we've been working towards enabling > >> pushing vendor/openzfs/* branches. There's one big issue that needs to > >> be corrected. Currently, we'll do one email per revision hash on such > >> imports, so openzfs would generate ~10k emails, which would be > >> undesirable. Li Wen is working on enabling one email per push for > >> vendor/* which would eliminate this problem. We hope to be doing test > >> pushes to the testing repo early next week, and if all goes well > >> enabling this in production shortly after. > >> > >> IMHO, you've made a compelling case: the size is small, the coupling > >> between the projects is tight and we get some extra benefit from > >> having a finer-grained vendor branch that we import from. The plan to > >> import directly from vendor/openzfs/zfs-2.1 would normally be > >> concerning because it's not following the usual main -> stable/X > >> workflow. In this case, though, since upstream follows that workflow > >> we won't lose things that get pushed to stable/13 that aren't also > >> relevant to main. There's at least some configuration needed to allow > >> the merge commits to stable/13, but we're still working out the last > >> details. > >> > >> So we'll be good to go soon (1-2 weeks until you can land commits, I > >> think). Does that work for you? > >> > >> Warner > >> > > > >_______________________________________________ > >freebsd-git@freebsd.org mailing list > >https://lists.freebsd.org/mailman/listinfo/freebsd-git > >To unsubscribe, send any mail to "freebsd-git-unsubscribe@freebsd.org" > _______________________________________________ > freebsd-git@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-git > To unsubscribe, send any mail to "freebsd-git-unsubscribe@freebsd.org"