Closed kjuli closed 1 year ago
question, before i even look at the code : why does this pull request list all commits since last august as part of this PR? im no pro on github, but i'm used to seeing only the commits, that differ from main/master? o_O
now, after a brief look at the code, it seem's you did some more thing than 'just' adding the lambda based handler. may i suggest to split unrelated things into two PRs? (at least to me, the added documentation and the lambda things appear kinda unrealted.) or at least mention both things in the PR dscription.
PS.: sorry for beeing an annoynace, but yesterday i took part in a bachelor thesis' code review and got some reminders on how to work with issues and PRs :x
PPS.: no need to change anything about this PR, just maybe keep in mind for later on : D
oooooouuuuuukeyyyy.... @kjuli i don't know what you did (if it's even your fault), but if i try to pull this repo, i get this:
git pull
fatal: refusing to merge unrelated histories
and if i compare my local git history (git log
) of the master branch with the commits on the remote master, all the commits are different (like, same author/date/message, but different hash).
however, the commit (hashes) of my local master branch, match with the comits listet here on the remote feature/lambdabasedhandler branch.
tbh, i think this i not how things are supposed to be^^" i'm not sure though, whether the remote ist broken, or whether my local clone is broken. maybe either of you can give me some hints or reproduce my problem? ^^"
Uff I think I messed things up 🥴
 I wanted to delete a file and I believe I rewrote the whole history of the git repo up until the point where buildAndRun
file was created. I actually just wanted to delete the file, but afterwards I got the same message as yours.
The way I was able to fix this on my local branch was to use git merge -Xours origin/master
if you want to merge the master branch and automatically only use the changes from your local branch. In your case though, I think you should use git merge -Xtheirs origin/feature/lambdabasedhandler
if you are locally already on the feature branch. Otherwise, you should be able to remain on the master branch and use the first command but with -Xtheirs
to accept the history from the remote branch and then simply checkout or rebase to the feature branch.This would also explain why all the commits from August are showing up, but the files changed are only the actual changes for this feature.
Btw the remote branch is not broken, it accepted the unintended history change and new people will be able to normally pull and push to the repository. It is just in our case that we either have to accept the history from the remote branch forcefully OR rewrite the history on the remote again to the old way. But if I am being honest, I really don't want to do the whole "return to the future" spiel again and risk a complete break up of the repo.I am still looking what I was actually doing and how it happened and will report it here, just to know what command we should NOT use in the future.
ups :x well, shit happens :D
your suggestion didn't work for me, but with a git pull origin master --allow-unrelated-histories --rebase
i could at least pull again.
i do now have the remote master history. thanx for the fast reply!
I am closing this PR in favor of the other PRs to fix the history issue
Added a mechanism to add new event handlers during runtime.
For example, one is able to retrieve the
SimulationDriver
instance and then do the following if needed:It registers a new event handler for the event
SomeEvent
and also assigns a string-based id, which can later be used to e.g. unregister this handler again.The only thing that is missing right now is adding new contracts during runtime (since it is not possible to add new annotations at runtime).