From owner-freebsd-git@freebsd.org Tue Apr 13 14:37:17 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 B16F15E2AAA for ; Tue, 13 Apr 2021 14:37:17 +0000 (UTC) (envelope-from uqs@freebsd.org) Received: from acme.spoerlein.net (acme.spoerlein.net [IPv6:2a05:fc87:1:5::15]) (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 (2048 bits) client-digest SHA256) (Client CN "www.spoerlein.net", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4FKSqd2MnBz4m0W; Tue, 13 Apr 2021 14:37:17 +0000 (UTC) (envelope-from uqs@freebsd.org) Received: from localhost (acme.spoerlein.net [IPv6:2a05:fc87:1:5:0:0:0:15]) by acme.spoerlein.net (8.16.1/8.15.2) with ESMTPS id 13DEb5PJ082526 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Tue, 13 Apr 2021 16:37:05 +0200 (CEST) (envelope-from uqs@freebsd.org) Date: Tue, 13 Apr 2021 16:37:05 +0200 From: Ulrich =?utf-8?B?U3DDtnJsZWlu?= To: Martin Matuska Cc: Warner Losh , Mateusz Guzik , Ryan Moeller , Alexander Motin , freebsd-git Subject: Re: OpenZFS branch tracking policy Message-ID: References: <41924e9d-9d61-6646-6c8f-e4458f94296e@FreeBSD.org> <30f529c1-6087-e704-8cc7-0c48a40b7430@FreeBSD.org> <9679ec9d-4916-92b7-ff70-0050d699875c@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/2.0.3 (2020-12-04) X-Rspamd-Queue-Id: 4FKSqd2MnBz4m0W X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [0.00 / 15.00]; local_wl_from(0.00)[freebsd.org]; ASN(0.00)[asn:39540, ipnet:2a05:fc87::/32, country:CH] 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: Tue, 13 Apr 2021 14:37:17 -0000 Hmm, I don't have an opinion on that one really. Cherry-pick of course only works on a single commit and will not record an additional parent, while a merge commit will have (at least) 2 parents. Some vendor branches sometimes have several commits in between a merge into head, so `git merge` is the natural extension of that. So only some folks can use cherry-pick and, as I said, I'm not sure what the recording of 2 parents gives us ... People with more vendor experience should chime in ... Cheers Uli On Mon, 2021-04-12 at 13:08:59 +0200, Martin Matuska wrote: >If we keep the "old way" than I have an additional question: > >Wouldn't a "git cherry-pick -Xsubtree=sys/contrib/openzfs" from the >vendor branch be a better way to go than "git merge >-Xsubtree=sys/contrib/openzfs"? Especially for stable/13, where I have >to "merge" in the whole new vendor/openzfs/zfs-2.1-release branch. > >mm > >On 12. 4. 2021 11:02, Ulrich Spörlein wrote: >> On Sun, 2021-04-11 at 01:03:30 +0200, Martin Matuska wrote: >>> Thank you for your comments, Warner. >>> >>> What I would like to know is the timing - how much time do we need to >>> resolve the issues. I can pull in the OpenZFS code up to commit >>> 3522f57b6 the "old" way. This is the last commit common to master and >>> zfs-2.1-release and can be cherry-picked to stable/13 the "old" way. >>> This will keep our code on par with openzfs-2.1-rc1 (rc2 is out now) and >>> I can add a 2-week MFC for stable/13 as usual but there are no >>> significant changes at all. After that we need to split main and >>> stable/13 and ideally move to direct tracking of OpenZFS. >>> >>> I have added some comments below. >> >> I think we should continue with the old way of squashing vendor >> changes in, for the main reason of bloat and slowdown for our users. >> Note that unlike SVN, a regular user who builds world will clone all >> of the git repo including all history. We have many more users than we >> have developers working on contrib software, so the slight convenience >> of a few FreeBSD devs comes at the cost of the majority of our users. :( >> >> I understand the confusion of a broken `git blame` and I'm wondering >> if it wouldn't be enough for the folks that want this to fetch the >> full OpenZFS repo into their FreeBSD repo. Then when the need arises >> to `git blame foo/bar.c` they see an "unhelpful" commit that says >> "upstream 01234abcdef was merged" upon which you can run `git blame >> 01234abcdef -- foo/bar.c` (paths will be different but it all can be >> hidden behind some script and git alias). >> >> Would that ease enough of the developers pain? >> >> I wish more stuff would move into ports (llvm, lldb) for reasons of >> size also. >> >> Cheers >> Uli