As mentioned in #2, this PR updates the state of the implementation to build upon the latest version of the upstream repository.
To do so, I performed a rebase against the updated master branch in my fork, dropped 72b5bd5917d3a220fecdf6bbb71020552a041ba3 (which had already been merged into the upstream project as d94b7b3b24734231fc7fc19704442019fa4cc6c7), and resolved any conflicts that were appearing.
The downside of this approach is that the history of the sl-2 branch is not compatible with the history in my personal fork anymore, therefore I used this fork's master branch as the target branch for now (which lacks a great number of upstream commits, therefore the currently huge size of this PR).
If merging this PR would make sense to you, could you maybe create a new branch based on the upstream master branch to use as a target instead?
As mentioned in #2, this PR updates the state of the implementation to build upon the latest version of the upstream repository.
To do so, I performed a rebase against the updated
masterbranch in my fork, dropped 72b5bd5917d3a220fecdf6bbb71020552a041ba3 (which had already been merged into the upstream project as d94b7b3b24734231fc7fc19704442019fa4cc6c7), and resolved any conflicts that were appearing.The downside of this approach is that the history of the
sl-2branch is not compatible with the history in my personal fork anymore, therefore I used this fork'smasterbranch as the target branch for now (which lacks a great number of upstream commits, therefore the currently huge size of this PR).If merging this PR would make sense to you, could you maybe create a new branch based on the upstream
masterbranch to use as a target instead?Resolves #2. CC @tanim-ics