Git client?

Hi,

Is there a git client available for RISC OS? If not, what do people use for source control when developing on RISC OS?

Cheers

Gareth

No Git client available. ISTR that someone (Theo?) attempted a quick port, but failed due to strange filenaming issues.

Personally, I use CVS and Git, via a Windows PC and Eclipse. On RISC OS, I think only CVS, SVN and possibly a very old port of RCS are available. I never had success with CVS over SSH, so followed the “develop on a PC” line of thought quite early. Once you are used to a full IDE, it is difficult to go back to StrongEd and Zap.

Not tried Git yet (just SCCS, PVCS, CVS and SVN). Probably will try Git soon. The source code is presumably GPL which means I can’t study it unfortunately…

At work I use IDE’s 8 hours a day which certainly have their advantages, although I’m fairly happy in vi too.

Personally, I love StrongEd and develop on RISC OS using that + Norcroft. Makes a nice refreshing change for me.

The git client is in the GCCSDK Autobuilder if you want to have a look at it there. Last time I tried it (which was probably a couple of years ago) it did compile. I can’t remember now the details of what didn’t work, but one thing was that the main git program launched subprograms but then the two didn’t communicate properly.

I didn’t pursue it anymore as I can use Git via a PC or Linux machine.

I didn’t pursue it anymore as I can use Git via a PC or Linux machine.

Did anyone?

It would be handy for committing stuff to NetSurf but I can go through OmniClient and do the commit via SSH from my Debian server.

We probably should have some kind of git.

We probably should have some kind of git.

And some kind of Mercurial, Monotone, Darcs, Fossil and Bazaar. And secure CVS and SVN. And graphical clients for all of those. And an IDE with version control connectors. And some of the more frequently used programming languages like Ruby, Rust, Go, Swift, Objective C, C#, Java, TypeScript, Tcl and of course a current version of Python. And an IDE supporting all those languages.

At the end of the day, RISC OS is just too far behind wrt development tools of all kind. GCCSDK is a noble effort, but is also seriously out of date compared to mainstream GCC. I think there is just no alternative to “do your thing on a competent development platform and compile there for RISC OS”, and that only helps when you are happy with the languages GCCSDK provides. But at least it is the solution for the tooling problem.

I think the easiest way is to run GIT on linux and mount it with NFS.

Steffen said

[wisdom]

All true, all very sad.

I was thinking about this thread recently. This whole thing bothers me a lot.

Because I already had the source I tried building Python3.7 just crosscompiling using GCCSDK in linux. Not using autobuilder. It gets surprisingly far through the build process before it fails.

So many up to date things would be nice. A person can dream.

To dig up an old thread, I did get git to build and it sort of works, but the way it works means it can end up forking to run itself again, and that bit seemed to fall over.

I have managed to get libgit2 to cross compile and run a very simple test on RISC OS – if I put the repo on HostFS I can check a file in on RISC OS and see it there on linux. I would like to try to do a small front-end for it to do a few basic things from RISC OS and see if there are any gotyas.

I did make some progress with python 3 (see another thread) too.

So much to do, so little time.

To dig up an old thread, I did get git to build and it sort of works, but the way it works means it can end up forking to run itself again, and that bit seemed to fall over.

Regular git?

I have managed to get libgit2 to cross compile and run a very simple test on RISC OS – if I put the repo on HostFS I can check a file in on RISC OS and see it there on linux. I would like to try to do a small front-end for it to do a few basic things from RISC OS and see if there are any gotyas.

Yes, libgit2 looks like it’s pretty easy to get working. A few months ago I was able to port SimpleGit (which uses libgit2 internally) to RISC OS, using the GCCSDK autobuilder:

https://www.riscosopen.org/forum/forums/1/topics/12640
https://www.riscosopen.org/forum/forums/11/topics/12657

In terms of libgit2, the main area that needs work is the filename translation. Meanwhile, the SimpleGit command is perhaps a bit too simple – common operations can be hard to perform, or even impossible (e.g. deleting branches). Plus it looks like we’re still waiting for a riscos.info maintainer to build & upload an official package.

As you say, so much to do, so little time.

Something that I became aware of recently is git9 which is a git client for Plan 9. It might not be very relevant to RISC OS, though it could still be worth looking at for ideas.

In terms of libgit2, the main area that needs work is the filename translation

It usually is. I guess there are different things to translate.

RISC OS uses . rather than /, so that need converting.

Filetypes need handling somehow. If your project has a “image.jpg” you’d want the right type, but what about the extension – does it become image or image/jpg. If you drop the extension then you could get clashes (image.jpg and image.gif). I guess that could be configurable per repo.

Finally some way to RISCOSify the structure of source code, so that foo.c becomes (ie. file foo extension ‘c’) becomes “c.foo” (file foo in directory ‘c’). That’s not strictly necessary I guess, but most things are going to need it!

Something that I became aware of recently is git9 which is a git client for Plan 9. It might not be very relevant to RISC OS, though it could still be worth looking at for ideas.

It looks like it’s some sort of file system. The idea of a ‘GitFS’ did cross my mind, but I wasn’t quite sure how it would work.

In terms of libgit2, the main area that needs work is the filename translation

It usually is. I guess there are different things to translate.

UnixLib handles a lot of stuff for us, so most git repositories from Unix/Windows land will “just work”, producing a folder structure which is compatible with RISC OS C/C++ compilers (see some of the notes in the !Help file). The big things that are missing are the ability to store RISC OS filetypes (e.g. currently if you store a sprite file, it’ll lose its filetype – which limits our ability to use git for RISC OS projects), and the ability to customise the behaviour on a per-repo basis.

RISC OS uses . rather than /, so that need converting.

Definitely. You need a clear mapping between RISC OS filename characters and “other OSes”. Something most emulators fail when looking at the various HostFS approaches.

Filetypes need handling somehow.

Use MimeMap, nothing else. Do not try to second-guess what the extension might or might not be – always translate “.” to “/”. Add “,xxx” filetype extensions if absolutely needed.

Finally some way to RISCOSify the structure of source code, so that foo.c becomes (ie. file foo extension ‘c’) becomes “c.foo” (file foo in directory ‘c’). That’s not strictly necessary I guess, but most things are going to need it!

Never ever include that in a versioning system. Do it as a seperate step, if you really need it. Even better, teach Norcroft to handle source/c additionally to c.source.

but what about the extension – does it become image or image/jpg.

Please… image/jpeg !
Just because DOS originally broke everything with a limit of three character filenames…

The idea of a ‘GitFS’ did cross my mind

Image filing systems are one of the most powerful features of RISC OS, but sadly under-exploited.

It could work, but does GCC bold modules? Libgit2 might compile with a later version of Norcroft than I have, though.

I’ve use the subversion port for RISC OS and that gave a choice of using svn properties or the “,xxx” file extension. Maybe something like this can be done for the git port.
I’ve also got a feeling that you can set an environment variable and unixlib will do the “,xxx” file extension for you, but I’ve not looked into it in detail.

Plus it looks like we’re still waiting for a riscos.info maintainer to build & upload an official package.

I’m not an official maintainer, but I have built and uploaded packages before. Unfortunately I’ve just upgraded my Ubuntu machine and so it may be a few weeks before I could do it.
When I’ve done this before for someone other than myself, I’ve always been in touch with them by email, so that they can double check the package I’ve built and uploaded is correct. I would want a similar contact if I were to do libgit2 and Simple Git.
I’m happy to do this for anything in the autobuilder, as once I’m set up again it’s fairly straightforward. What I don’t have time for is anything more than simple fixes to the build or packaging.

It could work, but does GCC bold modules?

I assume you mean “build”, not “bold”! I’ve not done anything but run the simple examples, but GCC can build modules. You do need to link them the scl though, so some functionality from the linux world may not be available.

I assume you mean “build”, not “bold”! I’ve not done anything but run the simple examples, but GCC can build modules. You do need to link them the scl though, so some functionality from the linux world may not be available.

Ha, yes. I will blame typing on my phone at the time :)

I’ve use the subversion port for RISC OS and that gave a choice of using svn properties or the “,xxx” file extension. Maybe something like this can be done for the git port.

Git is pretty poor in this regard – my understanding is that the only metadata files have is their filename and an ‘executable’ flag (which gets used for the Unix ‘executable’ attribute). So MIME mapping to/from unix file extensions, and using ,xxx extensions, are likely to be the two main ways we’d want to handle things.

Configuration would be the other tricky part – I still need to look into exactly how extensible the configuration files are. E.g. to allow repositories to specify their own filename/filetype mapping settings, is it OK for us to add RISC OS specific bits to .gitattributes files, or should we have our own .gitriscos file? And for any user settings, can those go in the standard git config files, or do we need custom ones of those too?

When I’ve done this before for someone other than myself, I’ve always been in touch with them by email, so that they can double check the package I’ve built and uploaded is correct. I would want a similar contact if I were to do libgit2 and Simple Git.

me at phlamethrower dot co dot uk

Configuration would be the other tricky part – I still need to look into exactly how extensible the configuration files are. E.g. to allow repositories to specify their own filename/filetype mapping settings, is it OK for us to add RISC OS specific bits to .gitattributes files, or should we have our own .gitriscos file? And for any user settings, can those go in the standard git config files, or do we need custom ones of those too?

I am no git guru, just a user that is forced to work with it daily.

My understanding is that there are user settings (usually .gitconfig), system settings and repository settings (.git/config). Tools like gerrit that are based on git just open up their own name space by prefixing all keys with gerrit. So just define a bunch of keys prefixed by riscos. and everyone will be happy.

Not sure if you need/want .gitattributes for something like that.

The difficult part will be to come up with a scheme that is easy enough to use for the simple case (i.e. all clients run on RISC OS and compile with a RISC OS-based toolchain) and still flexible enough for the general case (all clients, all systems, cross-compile and native compile). I am slowly becoming a fan of “convention over configuration”. So I’d say just hardwire the “.” to “/” transformation, and add ,xxx types for everything that is not a text file except the extensions already mapped to types by MimeMap.

Perhaps I am missing a million small but important details :-)

I’ve also got a feeling that you can set an environment variable and unixlib will do the “,xxx” file extension for you, but I’ve not looked into it in detail.

Close – there’s a riscosify_control flag for it, but no environment variable AFAICS. Also it doesn’t handle load/exec addresses, but I don’t think ROOL have any files like that in CVS, so we can probably ignore that.

Over the weekend I tweaked things a bit (a couple of UnixLib settings, and a fix for ‘sgit submodule’) and was able to successfully clone one of ROOL’s git repositories (although I haven’t tried diffing it against a known-good copy yet). There’s one filename translation issue which will need some thought (CDFS has a couple of files which have both Unix filetype extensions and RISC OS ,xxx extensions – but the RISC OS extensions are redundant, causing an asymmetric mapping between RISC OS and Unix/git form, causing sgit to think the files have been renamed), and also “sgit status” fails in an odd way when you’re in a submodule (may need a few rounds of debugging to find the cause – “sgit log” and “sgit branch” work fine, so it’s not a general issue with submodules), but other than that it’s looking promising.

So the main thing for us to do next will probably be to work out a way of allowing people to configure filename/type mapping. Random thoughts before lunchtime is over:

• I spotted that gitlab has added its own attributes to .gitattributes, so extending that is certainly one way of allowing repositories to control behaviour. User settings can go in .gitconfig.
• We’d probably want the default behaviour to be to enable suffix swapping (unix foo.c → RISC OS c.foo), but ROOL’s repositories are stored in RISC OS form (identical to CVS), so we’ll need repositories to be able to specify the default mode (e.g. via .gitattributes).
• UnixLib’s mapping of extensions to filetypes is reliant on MIMEMap, but we can’t rely on everyone having the same mapping file, so I’m thinking that it might also make sense to store mimemap info in .gitattributes as well. I.e. when you add a file with a new filetype (which has a mimemap entry on your machine), the git client automatically adds a .gitattributes entry so that everyone else who clones the repo will have the same mapping available. (the .gitattributes mappings will take priority over MIMEMap). Or there should at least be the option of adding an entry to .gitattributes.
• For the CDFS problem, we’d probably need to implement a fuzzy mapping system – e.g. when comparing directories, have git do a Unix → RISC OS → Unix round-trip conversion for the filename in the repository and use that to check against the (Unix form) of the working tree. We’ll also need to add code to detect (and throw an error) when two files in the repository have the same name under RISC OS.
• Depending on how complex things get (.gitattributes files can be placed anywhere in repositories, and there may be questions to answer WRT handling of submodules), we may need to replace/augment UnixLib’s code so that we can control the mapping for each element in a path.

Depending on how complex things get (.gitattributes files can be placed anywhere in repositories, and there may be questions to answer WRT handling of submodules), we may need to replace/augment UnixLib’s code so that we can control the mapping for each element in a path.

Actually, I guess it shouldn’t be that bad – the only time the configuration can change (i.e. a .gitattributes file can be activated or deactivated) is when we move from one Unix folder to another Unix folder. And the only path manipulation (not leafname/filetype manipulation) is suffix swapping, so even if you’re in RISC OS folder foo.bar.c, it doesn’t really matter whether the unix path is foo/bar/c (no suffix swapping) or foo/bar (suffix swapping for .c files), you can still find the correct .gitattributes files by walking up the layers of the unix path.

There is a potential problem if you’re in foo.bar.c and you have suffix swapping enabled and there’s a ‘c’ folder in the repository (confusion over whether files are in foo/bar/c or whether they’re C files in foo/bar), but in that case the system can hopefully detect that and complain. E.g. detect the case where there’s a ‘c’ folder in repository, and the attributes for foo/bar show that ‘c’ suffix swapping is enabled. If foo/bar/c has a .gitattributes file that disables suffix swapping, that wouldn’t be acceptable – to avoid uncertainty system should really require that foo/bar contains the .gitattributes which disables swapping.

Adding to a thread from many months ago – would there be any merit in creating a “LibGit2” module so that front end side could be written separately and in whatever language the author chooses? If the interface can be agreed on it would also in theory mean the two sides could run in parallel.

Hmm, I need to have another look at LibGit2 (I did get it to build ages ago with the GCC cross compiler).