Pikchr on github so that it's easy to clone

With Fossil 2.14:

 $ fossil clone https://pikchr.org

With older versions of Fossil, it's very slightly more difficult.

to allow contributions to the development of the tool.

It seems we're doing without CLA ceremony for this project — which fits with its zero-clause BSD license — so I suspect you simply have to ask drh for a commit bit.

Anyway, I'm reasonably certain drh wouldn't accept a GitHub PR, as such. He'd have to turn any PR he wanted to accept into a patch and commit it up through Fossil and push the change up to the mirror, which is more work all around.

Wouldn't it be better to just commit directly, get the middle man out of the way?

All of the on-line documentation is Markdown with embedded Pikchr. GitHub understands Markdown, but it does not (as of yet) understand Pikchr. So the GitHub clone wouldn't work for the documentation.

How about this: You convince GitHub to add Pikchr support to their Markdown interpreter, and once that is accomplished, I'll make sure there is a current clone of the Pikchr sources on GitHub. Deal?

I cannot even get pikchr to compile on windows without warnings (which I don't know whether to ignore or not). Please reply to https://pikchr.org/home/forumpost/f02ae7f95a so I can try out the tool.

How big a deal is it to get github to change something like that? Move mountains or code it myself?

Do not worry about the warnings. Or, if you are worried, post them here. I tried this:

cl /W4 -DPIKCHR_SHELL pikchr.c

This generated a single (silly) warning about using fopen() instead of fopen_s() - ignore that warning. The resulting executable seemed to work fine.

How big a deal is it to get github to change something like that?

I would really like to see GitHub support Pikchr in their Markdown implementation. Why don't you write to them and ask for this? The more community feedback in support of Pikchr that they receive, the more likely they are to add it.

I don't understand why GitHub needs to support Pikchr in their Markdown implementation. The files that are in a user repository can have Pikchr or not, GitHub could care less - it's just data.

Because the Pikchrs in the documentation are there to exemplify points in the text, so if they're rendered as plain text, the points don't get made properly.

Right up at the top of the user manual, for example, is this paragraph: "If you do this right, the output should appear as:" followed by a Pikchr. The output should appear as "line; box "Hello," "World!"; arrow"??

Anyway, what does moving the code to GitHub have to do with fixing Windows compiler warnings? I realize you want it, but it's hardly a precondition.

Just came to second this. I'm trying to clone the repository using fossil on Github Actions and I get:

Unable to verify SSL cert from pikchr.org SSL cert declined subject: CN = sqlite.org issuer: C = US, O = Let's Encrypt, CN = R3 sha256: 0adf1fbbf83495237711f6b84ea79097b2883d79534655ddc981f4ce867229ef server returned an error - clone aborted accept this cert and continue (y/N)? Clone done, sent: 0 received: 0 ip: Error: Process completed with exit code 1.

I now have to try and find a way around this whereas using git would involve a simple checkout without the need to install additional tools.

Many people just run a git mirror without the ability for anyone to submit issues or PRs for example. This allows people to easily consume Pikchr (great software btw!) and so increase the size of the ecosystem.

Now at https://github.com/drhsqlite/pikchr.

Are you not using the new ability to bind email addresses in the user contact details to Git commits, so that GitHub can match them to its users?

If you're avoiding it for privacy reasons, you have my permission to link my commits in this way.

You might end up with a mix of users who want their email address on file only for alerts from the repo, who don't want their commits linked to a GitHub user account this way. I've got the same situation in one of my repos, and I'm dithering about whether to unsubscribe them from alerts in order to allow the linkage for the rest.

A way to have it both ways would be nice, but no method of marking an email address in the user's contact details as used for one purpose but not the other comes to mind.

The reason that emails are omitted is that the GitHub mirror is (or was) driven by an anonymous clone of the canonical Pikchr repository. And, being an anonymous clone, it did not have access to the USER table containing email addresses.

I'll delete the existing mirror and reestablish it using from the canonical Pikchr repo. That should cause all of the email addresses to appear.

Thanks, but you're not getting credit for your own commits. Either:

1. You don't have contact info in your "drh" user record on that repo; or

2. You do, but it doesn't match one of the email aliases GitHub has on file for you; or

3. You're doing it on purpose, so I'll shut up now. :)

Incidentally, you don't have to completely delete the mirror to fix things like this, only the local Git tree. Rebuilding it and pushing it will overwrite things on the GitHub side, without apparently creating duplicates of everything.

Rebuilding it and pushing it will overwrite things on the GitHub side, without apparently creating duplicates of everything.

Huh. I didn't know that....

Shrug. Worked for me the time I re-pushed my repos after this email address mapping feature landed. If there are problems with doing it that way, I haven't noticed.