From owner-freebsd-git@freebsd.org Fri Apr 2 23:37:48 2021 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 CC7555B65D6 for ; Fri, 2 Apr 2021 23:37:48 +0000 (UTC) (envelope-from mm@FreeBSD.org) Received: from mail.vx.sk (mail.vx.sk [144.76.20.103]) by mx1.freebsd.org (Postfix) with ESMTP id 4FBxLN4c51z4ZCM; Fri, 2 Apr 2021 23:37:48 +0000 (UTC) (envelope-from mm@FreeBSD.org) Received: from mail.vx.sk (localhost [127.0.0.1]) by mail.vx.sk (Postfix) with ESMTP id 2E8331E25DC; Sat, 3 Apr 2021 01:37:42 +0200 (CEST) X-Virus-Scanned: amavisd-new at mail.vx.sk Received: from mail.vx.sk by mail.vx.sk (amavisd-new, unix socket) with LMTP id 5s--EOQy_7xE; Sat, 3 Apr 2021 01:37:42 +0200 (CEST) Received: from [10.9.8.144] (188-167-101-78.dynamic.chello.sk [188.167.101.78]) by mail.vx.sk (Postfix) with ESMTPSA id B21471E2657; Sat, 3 Apr 2021 01:37:41 +0200 (CEST) To: Warner Losh , Ed Maste Cc: freebsd-git References: <21c7313e-315c-ec48-9437-e0a3d4ec14d2@FreeBSD.org> From: Martin Matuska Subject: Re: OpenZFS branch tracking policy Message-ID: <41924e9d-9d61-6646-6c8f-e4458f94296e@FreeBSD.org> Date: Sat, 3 Apr 2021 01:37:41 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.7.1 MIME-Version: 1.0 In-Reply-To: Content-Language: en-US X-Rspamd-Queue-Id: 4FBxLN4c51z4ZCM X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.34 X-BeenThere: freebsd-git@freebsd.org X-Mailman-Version: 2.1.34 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: Fri, 02 Apr 2021 23:37:48 -0000 Hi Warner and Ed, 2.1-release has already been branched. The stable branch policy in=20 OpenZFS is somewhat strange, they make a staging branch for each=20 patchlevel release, but the commits are continuous. To have some idea how big the repo history is: $ git rev-list master --count 6662 $ git rev-list zfs-2.1-release --count 6650 master and zfs-2.1-release have 6650 common commits at the=C2=A0 moment $ git log master | wc -l 129868 (linecount - 4 * revcount) / revcount =3D linecount / revcount - 4 =3D=20 15,4938 comment lines per commit on average Initial commit was made in Feb 26, 2008. Yearly commit counts: $ git log master | grep -c -E '^Date:.* 2020 -[0-9]+$' 666 $ git log master | grep -c -E '^Date:.* 2019 -[0-9]+$' 535 $git log master | grep -c -E '^Date:.* 2018 -[0-9]+$' 428 Martin On 2. 4. 2021 20:15, Warner Losh wrote: > > > On Fri, Apr 2, 2021 at 11:56 AM Ed Maste > wrote: > > On Fri, 2 Apr 2021 at 11:50, Warner Losh > wrote: > > > > We'd always hoped that we'd be able to do subtree merges from > upstreams > > that use git into FreeBSD. The big worry, though, was that this > would > > needless bloat the repo with a lot of history. We don't want, > for example, > > all of LLVM's history in the tree. We'd always anticipated that > there'd be > > some things we'd just accept the history for, since it is similar= in > > character to the vendor branches (though of course a bit more). > > Note that if we do want to avoid bringing in the full history `git > subtree merge` supports a `--squash` option. This brings in the set= of > upstream changes as a single commit, without bringing along the > associated history. We will need to do more experimentation to conf= irm > that the full process, including bootstrapping, will work as we wan= t. > Assuming this all works it should allow us to forgo the use of a > FreeBSD-specific vendor branch in src. > > We've discussed mirroring any such 3rd-party source in some > FreeBSD-controlled repository. This would allow the project to reta= in > a full copy of the history, but avoid bloating src with it. > > I agree with Warner that we may want a different policy (full histo= ry > or snapshots) for different contrib sources. > > > Good points Ed. I'd forgotten about --squash. > > Martin, what's your timeline for wanting to implement these things?=20 > I'm unfamiliar with the OpenZFS schedules. > > Warner