Check out Janggi (Korean Chess), our featured variant for December, 2024.

Enter Your Reply

The Comment You're Replying To
H. G. Muller wrote on Tue, Dec 19, 2023 03:21 PM UTC in reply to François Houdebert from 08:52 AM:

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:

hgmuller@hgmuller-VirtualBox:~/jocly/src/games/chessbase$ git remote -v
nubati    ssh://[email protected]/~/hgm.nubati.net/git/jocly.git (fetch)
nubati    ssh://[email protected]/~/hgm.nubati.net/git/jocly.git (push)
origin    https://github.com/mi-g/jocly.git (fetch)
origin    https://github.com/mi-g/jocly.git (push)

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.


Edit Form

Comment on the page Jocly

Conduct Guidelines
This is a Chess variants website, not a general forum.
Please limit your comments to Chess variants or the operation of this site.
Keep this website a safe space for Chess variant hobbyists of all stripes.
Because we want people to feel comfortable here no matter what their political or religious beliefs might be, we ask you to avoid discussing politics, religion, or other controversial subjects here. No matter how passionately you feel about any of these subjects, just take it someplace else.
Avoid Inflammatory Comments
If you are feeling anger, keep it to yourself until you calm down. Avoid insulting, blaming, or attacking someone you are angry with. Focus criticisms on ideas rather than people, and understand that criticisms of your ideas are not personal attacks and do not justify an inflammatory response.
Quick Markdown Guide

By default, new comments may be entered as Markdown, simple markup syntax designed to be readable and not look like markup. Comments stored as Markdown will be converted to HTML by Parsedown before displaying them. This follows the Github Flavored Markdown Spec with support for Markdown Extra. For a good overview of Markdown in general, check out the Markdown Guide. Here is a quick comparison of some commonly used Markdown with the rendered result:

Top level header: <H1>

Block quote

Second paragraph in block quote

First Paragraph of response. Italics, bold, and bold italics.

Second Paragraph after blank line. Here is some HTML code mixed in with the Markdown, and here is the same <U>HTML code</U> enclosed by backticks.

Secondary Header: <H2>

  • Unordered list item
  • Second unordered list item
  • New unordered list
    • Nested list item

Third Level header <H3>

  1. An ordered list item.
  2. A second ordered list item with the same number.
  3. A third ordered list item.
Here is some preformatted text.
  This line begins with some indentation.
    This begins with even more indentation.
And this line has no indentation.

Alt text for a graphic image

A definition list
A list of terms, each with one or more definitions following it.
An HTML construct using the tags <DL>, <DT> and <DD>.
A term
Its definition after a colon.
A second definition.
A third definition.
Another term following a blank line
The definition of that term.