RISC OS project in git

It’s been a while I did anything with RISC OS. I have a project that I recently revisited a bit. It used to be in subversion but I’ve converted it to git and hosting it on Gogs on my NAS.

When I now tried doing something with it I initially tried SimpleGit. I was unaware of the other git client. This seems to handle the c and h directories nicely like I’d wanted. The git repository has file.c format (like the subversion repository used to have). However, I cannot push any of my changes, as pushing gives me a 401 error. I suppose I need to provide a username/password, but it doesn’t prompt me to do so, it just gives the error. Cloning with the ssh://…-url gives a helpfull error “libgit error: No detailed error message!” so I suppose that is not supported.

I also tried the newer “proper” git client. But this does not to the transition between file.c and c.file (or I don’t know how to activate that). So even though I suppose I can check in with that I cannot compile my stuff. Is that correct? Or can I? (Using the DDE – I’ve just ordered the latest version, but for now I’m on cc 5.76 from 2018).

What are my options? I’m not so keen on committing a change moving all the file.c files as c/file files although I suppose I could. Rewriting the git history so it looks like file.c has always been c.file is probably possible but sounds like a lot of work as well.

(We should have had an imagefs or something transitioning between file.c and c.file…)

Hi Jan-Jaap,

If you want an overview of the available options, here’s a YouTube playlist where each video describes different tools and approaches to using Git with or for RISC OS:

https://www.youtube.com/playlist?list=PLEnraaJ9VQfWDl5T4D0P51pG89KRzj0n1

It also includes a tutorial on SimpleGit, and I hope we can have a tutorial with the forthcoming ROOL’s git client too.

However, I cannot push any of my changes, as pushing gives me a 401 error.

The 401 error occurs when the client is unauthorized. This can happen for two different reasons:

1) As you’ve noted, a lack of username and password.

OR

2) You do not have an authenticated client (e.g., no authentication token support, etc.).
However, it is possible to authenticate a Git command line client (or a Git desktop client) using RSA keys, but this requires setting up things outside of RISC OS.

Cloning with the ssh://…-url gives a helpful error “libgit error: No detailed error message!” so I suppose that is not supported.

Have you tried using a command line Git client and running the command git clone? If so, the problem you encountered is likely due to one of the two points mentioned in the previous answer.

I also tried the newer “proper” Git client. But this does not handle the transition between file.c and c.file (or I don’t know how to activate that).

Git can store anything, so the c.file vs. file.c issue shouldn’t be a problem. Normally, it’s only an issue if, for example, you’re trying to use GitHub.com and want your C files to have syntax highlighting. To address several compatibility issues between RISC OS and GitHub.com, I created a template repository that everyone can use for their own projects (even on their own profiles on GitHub.com), and it’s available here:

https://github.com/RISC-OS-Community/StandardRepoTemplate

This template already includes tools to check code and utilities to transform c.file to file.c for automation on GitHub.com, as well as automated packaging using GitHub Actions (as discussed in other topics here).

I don’t know if this will help you, but if you are new to Git, I would not suggest using the template above. However, some of the tools there might be helpful.

So even though I suppose I can check in with that, I cannot compile my stuff. Is that correct? Or can I?

Again, Git has no issues between c.file and file.c, so if your files are in the c.file format, Git should be fine, and DDE is obviously fine. If instead, your files are in the file.c format, they will appear as file,c to your RISC OS system when transferred. In that case, yes, you’ll need a utility to convert the file names.

What are my options?

Try watching the videos—they may help you gain a more complete understanding than a few messages on this forum can provide.

Rewriting the Git history so it looks like file.c has always been c.file

I keep my repositories for RISC OS in the c.file format. For example, take a look at this one:

https://github.com/RISC-OS-Community/ZVector

You can clearly see that the files in the src directory are in the c.file format, and GitHub.com recognizes them as C files. This is because of the Template Repository I created and mentioned above.

When I need to compile these files on Linux, BSD, or macOS, I use a script that is also in the template repository. All I have to do, from the project root, is run:

% ./.rocog/scripts/ux-src gen

This script will discover all my source files in the src directory in the RISC OS format (regardless of the language, so it supports BASIC, Forth, Perl etc… not just C) and create a new directory (called ux-src in the project root) with symlinks in the file.c format while maintaining your original source tree structure.

This setup ensures that all security, DAST, SAST, and code-checking tools work correctly, and I can even use VSCode to edit my sources on Linux and then compile them on RISC OS using DDE (or GCC) via RPCEmu, either manually or in an automated way (using a headless RPCEmu).

I hope my English was clear enough, and that this post is helpful to you in some way.

(We should have had an imagefs or something transitioning between file.c and c.file…)

Rick Griffin created a utility for this kind of conversion, I use it for files coming from GIT, very easy to use and effective….

https://jeanmichelb.riscos.fr/Dev/Download/Conv_CH.zip

What are my options? I’m not so keen on committing a change moving all the file.c files as c/file files although I suppose I could. Rewriting the git history so it looks like file.c has always been c.file is probably possible but sounds like a lot of work as well.

Why are you not keen on committing such a change?

The files will move to the natural way that they’re named, and you won’t have any workarounds or other ‘magic’ going on. If you want other people to interact with your sources, having them naturally in the way that they’re going to be used is far more useful.

Yes, you could re-write the history, but again, why bother? Just move the files, commit and move on.

@Paolo Fabio Zaino

If you want an overview of the available options, here’s a YouTube playlist where each video describes different tools and approaches to using Git with or for RISC OS:

I am aware of the youtube playlist and have looked at some of the videos :)

2) You do not have an authenticated client (e.g., no authentication token support, etc.).
However, it is possible to authenticate a Git command line client (or a Git desktop client) using RSA keys, but this requires setting up things outside of RISC OS.

Right, that needs those keys. Stupid, I should have remembered that. Where do I place them on the RISC OS side? Somewhere inside !UnixHome or something?

Have you tried using a command line Git client and running the command git clone? If so, the problem you encountered is likely due to one of the two points mentioned in the previous answer.

Yes, that worked fine.

I don’t know if this will help you, but if you are new to Git, I would not suggest using the template above. However, some of the tools there might be helpful.

Not really, as I know a fair bit of git through my work and I know about the problems with file.c and c.file, but not the solutions :) My repository is in file.c and my build system wants c.file.

@Jean-Michel BRUCK

Rick Griffin created a utility for this kind of conversion, I use it for files coming from GIT, very easy to use and effective….

Thanks for the tip, I’ll take a look at this! :)

@Charles Ferguson

Why are you not keen on committing such a change?

That’s a good question. It goes against my ideas of how to use source control. Changes like this usually come back and bite you, but that is in my work where there is backporting of bugfixes and other mergings and stuff going on. In this little project there’s not much chance for that so it is valid to ask if that argument still holds water…

That’s a good question. It goes against my ideas of how to use source control.

Well that’s fair. If the source is from elsewhere, and you need to regularly merge upstream changes, you’ll have problems if you do that. But I got the impression that this is your source and that you’re the only contributor. If that’s the case then there’s little reason that you can’t change things. If you’re doing archaeology on the sources, you have the option to follow renames of files, so that shouldn’t be a problem.

As you say, doing backports and merging in-flight changes, is a problem if you maintain earlier releases, but again, I understood that this is your own project – unless you have your own long-lived branches, you might have issues. But even in that case, Git usually manages to track your changes.

Example: Not long ago I moved all my RISC OS python modules from riscos/pymods/*.py to riscos/pymods/(dir)/*.py where (dir) was core, driver, pyromaniac, select or thirdparty. At the time I had a number of branches in flight (about 12). I made the change on a branch, let the CI run, then merged the branch to master… then merged master into the in-flight branches. In all cases the rename was applied happily to files that already existed, and new files on the branches just had to be moved into the correct locations. So I’d be pretty comfortable with letting it just do its thing.

With sources that come from other components, I usually use symlinks to allow the files to coexist in both forms. This is the way that I manage a lot of the ports in the open source things on Github. Symlinking from foo.c to be riscos/c/foo is pretty simple – I usually just run something like:

for i in ../c/* ; ln -s "$i" (basename "$i").c ; end
for i in ../h/* ; ln -s "$i" (basename "$i").h ; end

in the riscos directory, when starting the project.