vendor/illumos merges
Mark Millard
marklmi at yahoo.com
Sat Apr 24 15:00:48 UTC 2021
On 2021-Apr-24, at 03:44, Ulrich Spörlein <uqs at freebsd.org> wrote:
> On Fri, 2021-04-23 at 17:26:33 -0400, Mark Johnston wrote:
>> Hi,
>>
>> Now that FreeBSD uses OpenZFS as the upstream for ZFS, vendor/illumos is
>> mostly unused. However, we still use illumos as an upstream for CTF
>> tools and DTrace, though there haven't been any imports in a while.
>>
>> illumos has put a lot of work into their CTF toolchain, and I'd like to
>> import that. There are a couple of snags that I'd appreciate some
>> guidance on.
>>
>> First, I believe I should delete now-unused ZFS code from the vendor
>> branch and merge the result to main. I did this locally and got an
>> empty merge, which is what I'd expect. Is there any problem with this?
>
> Why would you record this empty merge? If you clean up vendor/foo, just do that but don't merge a no-op back into main (nothing changed, after all).
>
>> Second, with Subversion we had both vendor/illumos and
>> vendor-sys/illumos, and now we just have the former, seemingly with
>> sys/* bits imported from vendor-sys. Some of the upstream commits touch
>> both userspace and kernel bits, but the merge targets for these in
>> FreeBSD are different: cddl/contrib/opensolaris vs.
>> sys/cddl/contrib/opensolaris. How should I merge into main in this
>> case? I don't really see any options other than to split each offending
>> upstream commit into two parts, one for userspace and one for the
>> kernel, and merge them separately.
>>
>> If it helps to look at the branch where I staged the upstream commits,
>> I've pushed it to vendor/illumos2 in https://github.com/markjdb/freebsd
>> .
>
> Can you clarify why the merging of the two might be an issue? Note that unlike subversion, in git there's no "merge a certain subtree" handling
It might be an ambiguous terminology context for what is being
referenced, but there is :
# man git-subtree
GIT-SUBTREE(1) GIT-SUBTREE(1)
NAME
git-subtree - Merge subtrees together and split repository into
subtrees
SYNOPSIS
git subtree add -P <prefix> <commit>
git subtree add -P <prefix> <repository> <ref>
git subtree pull -P <prefix> <repository> <ref>
git subtree push -P <prefix> <repository> <ref>
git subtree merge -P <prefix> <commit>
git subtree split -P <prefix> [OPTIONS] [<commit>]
. . .
Its usage has tradeoffs from what I can tell reading about
it as an alternative to submodules.
There is also a not-predefined-in-git alternative:
https://github.com/ingydotnet/git-subrepo#readme
> , all that is recorded is a tree of some form and then a set of parents or ancestor commits. (git is a content tracker, not really a VCS :)
>
> I was under the impression that userland and kernel imports/merges need to happen at the same time anyway, so I assume you would import all the bits under vendor/foo in 1 commit and then merge them in 1 commit into main. Is that not how it goes?
===
Mark Millard
marklmi at yahoo.com
( dsl-only.net went
away in early 2018-Mar)
More information about the freebsd-git
mailing list