OpenZFS branch tracking policy

[Ulrich Spörlein]

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