OK, I see your games were added to the master branch at github.com/mi-g/jocly. First question: how did you manage that? If I knew that, perhaps I can manage it too.
Since the mi-g/jocly repository was my original source, my git directly communicates with it. If I do "git remote -v" I see:
The fetching from 'origin' works; I just switched my local git to the master branch, and did a "git pull origin". This first drew a complaint that I had to remove a file "package-lock.json", which turned out to be owned by 'root'. I figured that this was a kind of safety measure to ensure my master branch would remain in sync with some Debian package, so I dared to get rid of it by renaming. After that the "git pull origin" did work, so all your commits now also appear in my local master branch. And I subsequently pushed that to my own git repository at hgm.nubati.net.
Now I am not really a git wizard, but I think the proper procedure would be to first "rebase" my hgm branch locally onto the new HEAD of master. If all the changes in the commits since the fork were independent (i.e. separated by more than 2 unchanged lines) this will not involve any changes in the data at all, it just changes the way git orders the commits.
Even if that would be the case it is no guarantee that the changes were compatible on the JavaScript level; one of us might have changed routines that the other was calling from a different file. And when we both have been editing the same file (like adding new games to the end of index.js) git will complain about dependencies during the rebase, and I would have to specify the desired outcome by hand.
But since we have been working on different games, and I tried to avoid changing the more basic Jocly files as much as possible, and then mostly in a backward compatible way, I don't expect many problems here. Main issue is the zobrist hashing for repetition detection; there are more files that directly accessed the Jocly API for this than I imagined, and to not break those I would have to adapt them when I commit my patch of the base-model.js for this. In my local git I did not make a systematic effort for this, and just fixed some games that I accidentally noticed were broken (such as Metamachy).
Anyway, after I rebased my hgm branch locally, and made sure everything still works, I can push it to the nubati on-line repository. Currently I have no idea how it could go to github from there; "push origin" does not work, as I have no account on GitHub, and even if I did it would probably only allow me to push to my own files there, not to mi-g/jocly.
OK, I see your games were added to the master branch at github.com/mi-g/jocly. First question: how did you manage that? If I knew that, perhaps I can manage it too.
Since the mi-g/jocly repository was my original source, my git directly communicates with it. If I do "git remote -v" I see:
The fetching from 'origin' works; I just switched my local git to the master branch, and did a "git pull origin". This first drew a complaint that I had to remove a file "package-lock.json", which turned out to be owned by 'root'. I figured that this was a kind of safety measure to ensure my master branch would remain in sync with some Debian package, so I dared to get rid of it by renaming. After that the "git pull origin" did work, so all your commits now also appear in my local master branch. And I subsequently pushed that to my own git repository at hgm.nubati.net.
Now I am not really a git wizard, but I think the proper procedure would be to first "rebase" my hgm branch locally onto the new HEAD of master. If all the changes in the commits since the fork were independent (i.e. separated by more than 2 unchanged lines) this will not involve any changes in the data at all, it just changes the way git orders the commits.
Even if that would be the case it is no guarantee that the changes were compatible on the JavaScript level; one of us might have changed routines that the other was calling from a different file. And when we both have been editing the same file (like adding new games to the end of index.js) git will complain about dependencies during the rebase, and I would have to specify the desired outcome by hand.
But since we have been working on different games, and I tried to avoid changing the more basic Jocly files as much as possible, and then mostly in a backward compatible way, I don't expect many problems here. Main issue is the zobrist hashing for repetition detection; there are more files that directly accessed the Jocly API for this than I imagined, and to not break those I would have to adapt them when I commit my patch of the base-model.js for this. In my local git I did not make a systematic effort for this, and just fixed some games that I accidentally noticed were broken (such as Metamachy).
Anyway, after I rebased my hgm branch locally, and made sure everything still works, I can push it to the nubati on-line repository. Currently I have no idea how it could go to github from there; "push origin" does not work, as I have no account on GitHub, and even if I did it would probably only allow me to push to my own files there, not to mi-g/jocly.