I re-verified that the git-tree state looks good after
the trouble addressed in commit 89023c38fc
(by the same approach - comparison to a "clean rebase").
I was actually a little surprised that simple git merge
did the right thing this time.
The one thing I can't fix is that some of staging commits are now
reachable from master even though they're not really applied in there
yet, but that's just temporary effect until the next merge to master.
I certainly don't envy any archeology hitting these commit ranges
(e.g. bisections).
I made a mistake merge. Reverting it in c778945806 undid the state
on master, but now I realize it crippled the git merge mechanism.
As the merge contained a mix of commits from `master..staging-next`
and other commits from `staging-next..staging`, it got the
`staging-next` branch into a state that was difficult to recover.
I reconstructed the "desired" state of staging-next tree by:
- checking out the last commit of the problematic range: 4effe769e2
- `git rebase -i --preserve-merges a8a018ddc0` - dropping the mistaken
merge commit and its revert from that range (while keeping
reapplication from 4effe769e2)
- merging the last unaffected staging-next commit (803ca85c20)
- fortunately no other commits have been pushed to staging-next yet
- applying a diff on staging-next to get it into that state
This reverts commit c778945806.
I believe this is exactly what brings the staging branch into
the right shape after the last merge from master (through staging-next);
otherwise part of staging changes would be lost
(due to being already reachable from master but reverted).
An unmatched double quote in installPhase broke the build in the last update.
Fix it.
Reported by @solson (thanks!).
Fixes: 21b9c04a2c ("basex: 8.6.6 -> 9.4.3")
