SimpleGit

For the brave: http://www.phlamethrower.co.uk/misc2/SimpleGit_simplegit-1.zip

http://www.riscos.info/pipermail/gcc/2018-November/006790.html

Also before anyone says anything, this is a simple implementation of a git client, not a git client that makes git simple ;-)

You are some kind om magical elf, right?

I am going to give it a try next time I have access to something RO.
Also, Git is pretty easy. SVN gives me the heebie jeebies. I use it but it makes me angry. More manageable with file manager extensions on other platforms though.

Also before anyone says anything

I’ll bite my lip but I bet Rick has something to say ;-)

Seriously though, this is great work Jeffrey. I’ll try it out when I can as well.

but I bet Rick has something to say ;-)

I’m one of the believers in being able to build RISC OS on RISC OS. If this helps, then it’s all good. :-)

Will we still have tarballs? Will they work with the unzip bz2 tool? Questions, questions, questions! (^_^)

I tried cloning GrafX2 from GitLab and it broke partway through with “libgit error (12): SSL error: unknown error”

When I have some more time I’ll try it with something from GitHub

Chris Gransden updated libgit2, fixing a few issues specific to RISC OS file handling: link

I’ve tested it with GitHub and it seemed fine. I’m quite excited actually, great job Jeffrey!
The lack of portable machines capable of running RISC OS (let’s hope the PineBook does a better job than my rather fragile LapDock) always meant that moving projects between my desktop machines (some of them located in different countries) made a mess of things. CloudFS kinda helped but unfortunately it’s not an ideal solution either. In fact I often had to use embosser labelled USB thumb drives instead. Nice retro touch but not all that efficient.

I tried cloning GrafX2 from GitLab and it broke partway through with “libgit error (12): SSL error: unknown error”

It worked OK when I tried it just now. Maybe to do with network data corruption.

I’ve updated sgit to use a later version of libgit2 v0.27.7 and also built with libssh2 so the ‘git://’ protocol should now work. Tested OK on gitbub.

I’m quite excited actually, great job Jeffrey!

So far I’ve only really done the easy (if slightly tedious) bit of working out the kinks in the autobuilder setup. Most of the thanks should go to the GCCSDK team for their work on the autobuilder, libraries, and compiler :-)

I’ve updated sgit to use a later version of libgit2 v0.27.7 and also built with libssh2 so the ‘git://’ protocol should now work. Tested OK on gitbub.

Cool. Feel free to submit those changes (I hadn’t started work on that yet).

Cool. Feel free to submit those changes (I hadn’t started work on that yet).

I’ve added the changes to build simplegit with libgit2 0.27.7 and libssh2.

Thanks to Alan Buckley, SimpleGit is now available via Packman / riscos.info.

http://www.riscos.info/packages/DevelopmentDetails.html#Simplegit-Libgit2

New test version which supports “,xxx” suffixes for storing filetypes (so should be usable for most RISC OS projects), and can successfully clone products from ROOL’s gitlab server.

http://www.riscos.info/pipermail/gcc/2019-May/006827.html

http://www.phlamethrower.co.uk/misc2/simplegit-libgit2_639-4.zip

(n.b. cloning the Disc product as in the given example takes around 20 minutes on my SSD-equipped Titanium – not sure how much slower it’ll be on lesser machines)

Trying to build Disc on a Titanium with simplegit 639-4 and this :-

set UnixEnv$sgit$sfix ""
sgit clone https://gitlab.riscosopen.org/Products/Disc.git Disc
dir Disc
sgit submodule init
sgit submodule update

It error’d :-

Starting phase resources ...

Cleaning Messages...
amu -E  -k clean COMPONENT=Messages TARGET=Messages NUMLOCALE=01
ADFS::ROOL.$.ROOLgit.Disc.RiscOS.Sources.Internat.Messages.Makefile: would not open
AMU: error reading makefile
Error running make clean on module 'Messages'.
Error creating directory 'Install.ROOL.Disc'.
Fatal error creating directory 'Install.ROOL.Disc'.
Batched errors...
Error running make clean on module 'Messages'.
Error creating directory 'Install.ROOL.Disc'.

The file that would not open is not there.

Trying with git on the mac and the download failed :-

Unable to checkout '431bcb1a94ff84c4951a9b240fe07032f40d2b88' in submodule path 'RiscOS/Sources/Desktop/Wimp'

Am I doing anything wrong, a not entirely unreasonable supposition.

Starting phase resources …

You shouldn’t do a “resources” build for the Disc product. You only want ‘Export headers’, ‘Export libraries’, and ‘Install disc’.

Unable to checkout ‘431bcb1a94ff84c4951a9b240fe07032f40d2b88’ in submodule path ‘RiscOS/Sources/Desktop/Wimp’

Most likely the non- UTF-8 filename discussed here

(n.b. note that I haven’t actually tried building the sources fetched via git – only done a diff against a tree fetched on Linux to make sure simplegit was fetching things correctly)

You shouldn’t do a “resources” build for the Disc product.

A mistake I have made previously!

Thanks, the simplegit build has completed.

And for my next mistake, possibly!

I have built a Titanium ROM.

dir <Obey$Dir>
set UnixEnv$sgit$sfix ""
sgit clone https://gitlab.riscosopen.org/Products/Titanium.git Titan
dir Titan
sgit submodule init
sgit submodule update
echo finished

It turned out to be OS5.26.

The sources visible in Explore GilLab are 5.27.

https://gitlab.riscosopen.org/RiscOS/Sources/Kernel/blob/master/Version

It turned out to be OS5.26.

Correct. AFAIK ROOL haven’t set up the “dev” products yet. Possibly there’s some head-scratching going on as to how best deal with some awkward aspects of git submodules (you can get them to track branches instead of specific commits – but you still need to make commits to the parent repository to “move them forward”, which seems like it could result in annoying merge conflicts).

AFAIK ROOL haven’t set up the “dev” products yet.

Thanks for that. The good news is that simple git works very well. Thanks for that as well.

AFAIK ROOL haven’t set up the “dev” products yet.

Given that ROOL are now building for download ‘dev’ products is it possible to directly ‘sgit’ these yet and if so what needs to be done to the script above.

TIA, assuming I am not being too previous.

AFAIK ROOL haven’t set up the “dev” products yet. Possibly there’s some head-scratching going on as to how best deal with some awkward aspects of git submodules (you can get them to track branches instead of specific commits – but you still need to make commits to the parent repository to “move them forward”, which seems like it could result in annoying merge conflicts).

Silly me – ROOL are already using branch-tracking submodules. So (with standard git) you can just do “git submodule update —remote” from the root of the repository to pull any changes & update the submodules to the new tip of the relevant branches.

And in reality, although you’d typically want to do a local commit to clean up your status view, there’s no need to push that commit to the remote server (especially if you’re working on code changes, since you’ll have updated some of the submodules to point to your forks/clones). So pushes are only needed when components are added/removed or changed to different branches (or to tag stable builds) – which should be rare enough to not be too much of a nuisance.

Of course, this doesn’t help SimpleGit users, since that currently lacks support for the “—remote” option.

So (with standard git) you can just do “git submodule update —remote” from the root of the repository to pull any changes & update the submodules to the new tip of the relevant branches.

Magic!! Many thanks indeed.

I have just retrieved the OS5.27 Titanium ROM using git on the Mac, tar/bz2’d it on the Mac and built it on the Titanium. Better still the ROM is running on the Titanium.

It does not appear to have messed anything up at all but the Mac git reported an "Unable to checkout … in submodule path ‘RiscOS/Sources/Desktop/Wimp’ which is the file with the silly name in TestO in Wimp as previously mentioned. As it is the last item in the terminal it looked as if the checkout stopped at that point, but the ROM did build so it is only the one file missing.

Thanks for that, there was not the remotest chance of me working this out for myself.