This PR brings up an interesting point: how do we want keep the OpenZFS repo up
to date with illumos changes? The [initial
commit](https://github.com/openzfs/openzfs/commit/c29590968d8c4b9679d314de2e57779f523e3cc5)
did not include any history, but the entire illumos history was eventually
[merged in]
(https://github.com/openzfs/openzfs/commit/5e0929bd169e776fb375a8c75f5736f1cae6d9df).
I think the way that we are rebasing PRs on top of the current OpenZFS head is
great, and it lends itself to us just continuously rebasing the OpenZFS tree on
top of the illumos tree. This way, we can think of git diff OpenZFS...illumos
as the set of things that still need to get put back into illumos.
For an example of why the current merge in strategy will get confusing, the
results of [this PR](https://github.com/openzfs/openzfs/pull/13) has two
different commits associated with it
[OpneZFS](https://github.com/openzfs/openzfs/commit/b621ee9a67a0184ee2eb2d7461a1e7966f0e45d2)
[illumos](https://github.com/illumos/illumos-gate/commit/c71c00bbe8a9cdc7e3f4048b751f48e80441d506)
In a rebase strategy, the first SHA would be left off the rebase when the
change was finally upstreamed. Less than ideal that the SHA in the PR will not
show up in the log, but we can either post the new SHA in the PR, or just
ignore it because it will still have the same illumos ticket ID, which is easy
to search for.
Looks like the current strategy has lead to a rebase conflict, but if anyone
would like to see my idea attempted, I would be willing to work through it and
push my changes to a personal fork.
---
Reply to this email directly or view it on GitHub:
https://github.com/openzfs/openzfs/pull/28#issuecomment-153352148
_______________________________________________
developer mailing list
[email protected]
http://lists.open-zfs.org/mailman/listinfo/developer
