From owner-freebsd-git@freebsd.org Fri Apr 16 19:24:25 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 A70C05DC747 for ; Fri, 16 Apr 2021 19:24:25 +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 4FMR3Y1crSz4l0Q; Fri, 16 Apr 2021 19:24:25 +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 106791D8A0A; Fri, 16 Apr 2021 21:24:18 +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 uFDBWgb9BK1p; Fri, 16 Apr 2021 21:24:17 +0200 (CEST) Received: from [10.9.8.122] (188-167-101-78.dynamic.chello.sk [188.167.101.78]) by mail.vx.sk (Postfix) with ESMTPSA id 8C2331D88CF; Fri, 16 Apr 2021 21:24:17 +0200 (CEST) To: Warner Losh , =?UTF-8?Q?Ulrich_Sp=c3=b6rlein?= Cc: Mateusz Guzik , Ryan Moeller , Alexander Motin , freebsd-git References: <41924e9d-9d61-6646-6c8f-e4458f94296e@FreeBSD.org> <30f529c1-6087-e704-8cc7-0c48a40b7430@FreeBSD.org> <9679ec9d-4916-92b7-ff70-0050d699875c@FreeBSD.org> From: Martin Matuska Subject: Re: OpenZFS branch tracking policy Message-ID: <2b404ead-d862-c4ba-41cd-4ceb1246ce6f@FreeBSD.org> Date: Fri, 16 Apr 2021 21:24:17 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.8.1 MIME-Version: 1.0 In-Reply-To: Content-Language: en-US X-Rspamd-Queue-Id: 4FMR3Y1crSz4l0Q 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:24940, ipnet:144.76.0.0/16, country:DE] 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, 16 Apr 2021 19:24:25 -0000 Thank you guys for your input. OpenZFS 2.1 has already gone -RC3, eliminating even more diffs the code=20 in our tree. I have merged OpenZFS-2.1 RC1 the old way up to the last common commit.=20 I don't know who or what body is in charge to make a decision on this=20 matter but I would be very happy if a decision is made. I am personally=20 slightly in favor of merging directly from OpenZFS as it makes my work=20 easier and less prone to mistakes but I don't object doing it the "old"=20 way. But even the "old" way is going to be different, as it would mean=20 doing vendor merges into stable/13 what we are not used to. On the other = hand I do "squashed" imports anyway so I could cherry-pick from the new=20 vendor branch into stable/13 as well. One way or another, I would like to continue pushing recent OpenZFS code = to our tree. Martin On 13. 4. 2021 18:39, Warner Losh wrote: > > > On Tue, Apr 13, 2021 at 8:37 AM Ulrich Sp=C3=B6rlein > wrote: > > 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. > > > Correct. > > 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 ... > > > So for normal, low velocity updates, there's little benefit from doing = > more than what we've done with vendor imports. > > But for OpenZFS I think there's three primary values from store their=20 > branches in our tree and doing merge commits: > > (1) git blame works > (2) it's possible to bisect down to the exact commit > (3) Having the merge commits recorded as merge commits makes future=20 > commits easier (just like vendor branches). > > For most things, I agree with Uli: we should have some flavor of=20 > 'squash' commit that's not really a merge commit to do this.=C2=A0 But = for=20 > OpenZFS, I think there's enough synergy between the two project that=20 > having their branches in our tree would be a net win for both groups. > > Warner > > 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=3Dsys/contrib/openzfs" from = the > >vendor branch be a better way to go than "git merge > >-Xsubtree=3Dsys/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=C3=B6rlein 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 an= d > >>> 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 t= he > >> full OpenZFS repo into their FreeBSD repo. Then when the need > arises > >> to `git blame foo/bar.c` they see an "unhelpful" commit that say= s > >> "upstream 01234abcdef was merged" upon which you can run `git bl= ame > >> 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 >