Date: Tue, 13 Apr 2021 10:39:44 -0600 From: Warner Losh <imp@bsdimp.com> To: =?UTF-8?Q?Ulrich_Sp=C3=B6rlein?= <uqs@freebsd.org> Cc: Martin Matuska <mm@freebsd.org>, Mateusz Guzik <mjg@freebsd.org>, Ryan Moeller <freqlabs@freebsd.org>, Alexander Motin <mav@freebsd.org>, freebsd-git <freebsd-git@freebsd.org> Subject: Re: OpenZFS branch tracking policy Message-ID: <CANCZdfrL=194g-yn95R_qEYsyGf4O=KYNdHvoNRqcRkK7xkSBA@mail.gmail.com> In-Reply-To: <YHWskVAE3iL8DyYX@acme.spoerlein.net> References: <CAPyFy2DS=nsE3-JQdqQC797xQhAiBACkuyA%2BcxkcRY0yeB_6=w@mail.gmail.com> <CANCZdfoPm0tfDpBTU8ORy-_Oa-tkiNX0_MeAdJn0T5ZJdQe6MQ@mail.gmail.com> <41924e9d-9d61-6646-6c8f-e4458f94296e@FreeBSD.org> <30f529c1-6087-e704-8cc7-0c48a40b7430@FreeBSD.org> <CANCZdfp3EJ%2BbrNM02Sfzu_Y42VDEADiApFaX0V9bu_jb5NWd4w@mail.gmail.com> <f8d7a7f3-63a2-434f-054c-fadb9131cf82@FreeBSD.org> <CANCZdfoPzNFSp2sW94Ken=u7DstHL_BWFmjV5MBD4cRBo3t_Uw@mail.gmail.com> <9679ec9d-4916-92b7-ff70-0050d699875c@FreeBSD.org> <YHQMru4/ay8lINSk@acme.spoerlein.net> <da88bd06-7e79-3d2c-38ee-84424a3cef1d@FreeBSD.org> <YHWskVAE3iL8DyYX@acme.spoerlein.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, Apr 13, 2021 at 8:37 AM Ulrich Sp=C3=B6rlein <uqs@freebsd.org> wrot= e: > 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 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 commits easier (just like vendor branches). For most things, I agree with Uli: we should have some flavor of 'squash' commit that's not really a merge commit to do this. But for OpenZFS, I think there's enough synergy between the two project that 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 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 >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CANCZdfrL=194g-yn95R_qEYsyGf4O=KYNdHvoNRqcRkK7xkSBA>