log in | register | forums
Show:
Go:
Forums
Username:

Password:

User accounts
Register new account
Forgot password
Forum stats
List of members
Search the forums

Advanced search
Recent discussions
- uniprint upgraded to 4.50 (News:)
- PhotoDesk 3.23 released (News:)
- R-Comp reveals N.Ex.T Boxes - the successor to the i.MX6 (News:)
- RISCOSbits at Wakefield Show 2024 (News:)
- R-Comp releases Genealogy v2 (News:)
- Will we see 5.30 released at Wakefield show? (News:1)
- Sine Nomine updates RiscOSM and Impact (News:)
- Netfetch version 5.55 released (News:)
- Prizes for Wakefield Show announced (News:)
- Heretic update from R-Comp (News:)
Related articles
- RISC OS 5.30 arrives
- uniprint upgraded to 4.50
- PhotoDesk 3.23 released
- R-Comp reveals N.Ex.T Boxes - the successor to the i.MX6
- RISCOSbits at Wakefield Show 2024
- R-Comp releases Genealogy v2
- Sine Nomine updates RiscOSM and Impact
- Netfetch version 5.55 released
- Will we see 5.30 released at Wakefield show?
- Prizes for Wakefield Show announced
Latest postings RSS Feeds
RSS 2.0 | 1.0 | 0.9
Atom 0.3
Misc RDF | CDF
 
View on Mastodon
@www.iconbar.com@rss-parrot.net
Site Search
 
Article archives
The Icon Bar: News and features: Updated RISC OS Git client sent to beta testers
 

Updated RISC OS Git client sent to beta testers

Posted by Mark Stephens on 06:55, 21/9/2023 |
 
ROOL have sent a new beta release of the RISC OS Git client to registered testers.

Git is a really important Version control system. Git is also the basis of platforms for hosting code such as GitHub and GitLab (as well as lots of other systems such as Bitbucket). So if we want to use these platforms for RISC OS development, and we want to encourage developers onto RISC OS, a Git client for RISC OS is a critical part of our toolset.
 
The latest beta version now implements the reset command (for a soft, mixed or hard commit) as well as fixing issues reported/ideas suggested by testers in previous versions. So you cannot do an empty initial commit and Double-click on a file in the Gui does a diff.
 
This is still a beta release, but definitely coming along and works nicely on my RISC OS systems!
 
If you would like to try it yourself, I am sure ROOL would welcome some more testers if you contact them.
 
If you want to use Git for developing RISC OS, ROOL has a nice cheatsheet here.
 
  Updated RISC OS Git client sent to beta testers
  nytrex (09:54 21/9/2023)
  richw (18:13 21/9/2023)
  hubersn (16:10 22/9/2023)
    richw (17:11 22/9/2023)
    SparkY (21:33 22/9/2023)
      hubersn (21:53 23/9/2023)
        pittdj (07:12 24/9/2023)
          andymarks (09:34 24/9/2023)
          hubersn (15:59 25/9/2023)
            richw (20:38 25/9/2023)
              hubersn (15:10 26/9/2023)
  gerph (19:23 24/9/2023)
 
Alan Robertson Message #125494, posted by nytrex at 09:54, 21/9/2023
Member
Posts: 103
Having Git on RISC OS will be really nice.
  ^[ Log in to reply ]
 
Richard Walker Message #125496, posted by richw at 18:13, 21/9/2023, in reply to message #125494
Member
Posts: 66
I don't quite understand this bit:

"So you cannot do an empty initial commit and Double-click on a file in the Gui does a diff."

Should 'cannot' be 'can now'?

Anyway, this all sounds positive. It is such a shame that the platform doesn't have a native Git client at the moment. I think a visual diff is key - but would have no problem with the less-used items remaining command-line only.
  ^[ Log in to reply ]
 
Steffen Huber Message #125497, posted by hubersn at 16:10, 22/9/2023, in reply to message #125494
Member
Posts: 91
Did I miss the announcement that the Git client reached beta state?

Or is that one more "secret bounty project" with a bit suboptimal communication by ROOL? Like publishing RO5.30 RCs without telling anyone properly?
  ^[ Log in to reply ]
 
Richard Walker Message #125498, posted by richw at 17:11, 22/9/2023, in reply to message #125497
Member
Posts: 66
Yeah, it is all a bit cloak-and-dagger, isn't it? It's like RISC OS Developmnents and/or R-Comp are showing ROOL the way. wink

What I have discovered is that you need to keep an eye on:
https://www.riscosopen.org/content/documents/bounties

and there can be status updates sneaked in.

Shame about USB.
  ^[ Log in to reply ]
 
Gavin Smith Message #125499, posted by SparkY at 21:33, 22/9/2023, in reply to message #125497
Danger! Danger! High Voltage!
Posts: 697
Did I miss the announcement that the Git client reached beta state?
I'm not sure it was a secret. I wish ROOL could find a way to communicate the work that goes on behind the scenes better, but the Git client progress has been reported in a number of places, including the previous issue of Archive (Vol.26, Issue 3).

https://www.archivemag.co.uk/covers/gitscreenshot.png


Or is that one more "secret bounty project" with a bit suboptimal communication by ROOL? Like publishing RO5.30 RCs without telling anyone properly?
Well, I don't think that's fair at all. There was this:
https://www.riscosopen.org/news/articles/2022/09/29/clock-ticks-towards-5-30-finishing-time

And the Downloads page refers to the RCs right at the top. There is a page showing progress at https://www.riscosopen.org/content/downloads/stable-release-status (including the Pi 400 rev1.1's Ethernet chip now working).
  ^[ Log in to reply ]
 
Steffen Huber Message #125500, posted by hubersn at 21:53, 23/9/2023, in reply to message #125499
Member
Posts: 91
Did I miss the announcement that the Git client reached beta state?
I'm not sure it was a secret. I wish ROOL could find a way to communicate the work that goes on behind the scenes better, but the Git client progress has been reported in a number of places, including the previous issue of Archive (Vol.26, Issue 3).

https://www.archivemag.co.uk/covers/gitscreenshot.png
It is developed as a bounty ffs. If it really can't be developed in the open (like...erm...in GitLab perhaps? Where it could be reviewed and tested by knowledgeable people?), at least the availability of a beta version MUST BE ANNOUNCED SOMEWHERE ON THE ROOL SITE. Sorry for shouting.



Or is that one more "secret bounty project" with a bit suboptimal communication by ROOL? Like publishing RO5.30 RCs without telling anyone properly?
Well, I don't think that's fair at all. There was this:
https://www.riscosopen.org/news/articles/2022/09/29/clock-ticks-towards-5-30-finishing-time
A news posting one year ago, before RC1 was available, and talking about "preview versions" (is this the same thing as a release candidate? Or something else?). And Release Candidates being produced every month (so we have RC12 now? If not, why not? Where is the progress report? Any obstacles someone might be able to help? Administrative problems? Nobody knows.)

No news posting for RC1, RC2, RC3, RC4. Why? Is the next stable release version of RISC OS not the only really important thing that ROOL needs to manage? Apparently not. But what is it then?


And the Downloads page refers to the RCs right at the top. There is a page showing progress at https://www.riscosopen.org/content/downloads/stable-release-status (including the Pi 400 rev1.1's Ethernet chip now working).
OK, now go to the downloads page. Follow the link to download RC4. What is a "Stable release candidate" - something else than a "Release Candidate"? And note that it says it is "Preview RC4 of the forthcoming RISC OS 5.3x stable release" - so not for the RISC OS 5.30 version? Because it says 5.31 in the next column? And what is a "Preview RC4"? Will it be followed by the "Real RC4" soon?

Now download the archive. Up until now, you might have expected all the ports to be available in this RC archive. After all, you were asked to test it and nobody said anything different. Turns out that this is not the case and only a small subset of ROMs are there (incidentially for the four oldest platforms - go figure). So...if I want to help identify bugs before the next stable release for...say the Raspberry Pi...what do I do? Test the latest 5.29 instead? But what is the difference between 5.30 RC4 and 5.29-Nightly? This is really a big mess, and the communication is terrible.

I recently followed a discussion forum where someone wanted to find out how to start developing RISC OS by just looking at the ROOL site. He failed miserably. The whole RISC OS thingy is only understandable to the insiders that follow it for the last 15 years or so. Not the way to grow a community.
  ^[ Log in to reply ]
 
David Pitt Message #125501, posted by pittdj at 07:12, 24/9/2023, in reply to message #125500
Member
Posts: 5
But what is the difference between 5.30 RC4 and 5.29-Nightly?
At the time of issue the contents of OS5.31 RC4 and the beta OS5.29 were identical except for the UtilityModule version numbers.
  ^[ Log in to reply ]
 
Andy Marks Message #125502, posted by andymarks at 09:34, 24/9/2023, in reply to message #125501
Member
Posts: 5
I'm not sure we're not all missing the fact that there is a candidate for a 25 year old machine, (and a nearly 20 year old machine) and nothing for probably the most ubiquitous ARM board in the world, that is still in production, and will be for a few more years.

I can't help thinking that the focus is slightly out of kilter with ANY efforts to try to bring new people on board.

I'm aware that the IOMD branch is the most downloaded (for emulators?) but I'm not sure we should be investing in that more than the Pi.
  ^[ Log in to reply ]
 
Charles Justin Ferguson Message #125503, posted by gerph at 19:23, 24/9/2023, in reply to message #125494
Member
Posts: 35
You have been able to use Git on RISC OS with RISC OS Pyromaniac for quite some time. Although the client was first envisioned about 3 years ago - https://asciinema.org/a/305986 shows the very first prototypes - the current implementation is reasonably fully featured and can be used as a regular client.

Example video showing how to use Git to clone, make changes and commit code here:

https://www.youtube.com/watch?v=qMTiNNncYww

There's a small example here of building with RISC OS Pyromaniac which incidentally clones the source code for a repository. It doesn't use much of git, but this is largely showing how simply you just use git as you'd expect:

https://presentations.riscos.online/live/building-beebit.html

There's a short video, with no commentary, demonstrating how to commit some code to a repository after making a change. This was largely to demonstrate that there's nothing special about committing changes in RISC OS Pyromaniac compared to doing it on Linux - except your filenames are (mostly) native format. Also, when you need to provide commit messages an external editor can be used:

https://share.gerph.org/s/gkOU8Rv60AH0Wji

Even logging in to the client can give you an external prompt - when a username and password are required, the external command invoked allows you to display a dialogue box or prompt at the command line:

https://pyromaniac.riscos.online/examples/wxwidgets-requestinput-2022-12-26.mp4

And, of course, RISC OS Pyromaniac's Git implementation - general usage, commands and system variables variables - are documented on the website:

https://pyromaniac.riscos.online/pyromaniac/prm/programmers/pyromaniacgit.html

You can, of course, use git on https://shell.riscos.online and as part of any CI jobs invoked on the RISC OS build service at build.riscos.online.

Basically, git on RISC OS Pyromaniac has become so run-of-the-mill that the fact that I'm using it in RISC OS isn't generally of note. Looking at my changelogs - https://pyromaniac.riscos.online/pyromaniac/CHANGELOG.html - I've not touched it since January, which means it's pretty stable and hasn't needed fixes.

As usual, if you want to test out RISC OS Pyromaniac the shell and build service offer an online mechanism, and you can drop me an email at gerph@gerph.org if you want to play with it directly.

--

Whilst, of course, the client for RISC OS native is nice, I would assume that the client would work pretty much the same way. Therefore, the demonstrations provided here (or in any of the other demonstrations of using git - https://www.youtube.com/@RiscosCommunityOnGithub/videos - including SimpleGit on RISC OS) would still be useful to anyone learning about it.

Interoperability is key, so it is highly unlikely that there will be many differences in use between git clients - users should be able to use any guide and client.
  ^[ Log in to reply ]
 
Steffen Huber Message #125504, posted by hubersn at 15:59, 25/9/2023, in reply to message #125501
Member
Posts: 91
But what is the difference between 5.30 RC4 and 5.29-Nightly?
At the time of issue the contents of OS5.31 RC4 and the beta OS5.29 were identical except for the UtilityModule version numbers.
Interesting. I somehow assumed that there is a more usual release candidate/rampdown phase strategy employed, like creating a branch where only showstopper fixes are applied and normal development continues on the main branch.

What is the sense in making RCs then anyway, if you control the RC phase by only letting through stabilizing changes? Surely the nightly build is a much better Release Candidate then?

Is there any documentation available about ROOLs thinking process here, and preferably also a confirmation that what you described is the way things work? I don't doubt what you say, I just strongly think that something as important as a release strategy should be publically documented somewhere. I would be very interested in a rationale for not putting out RCs for all platforms. I cannot think of a good reason for that.
  ^[ Log in to reply ]
 
Richard Walker Message #125505, posted by richw at 20:38, 25/9/2023, in reply to message #125504
Member
Posts: 66
I think it's pretty simple for ROOL to control what ends up in the build. They are in control of what gets merged, so they don't even need to faff about with branches: they can simply only merge things which are important and/or safe enough to include in the release.

I find the general lack of communication in the RISC OS world entirely typical... but it's been like this since day 1, hasn't it? When do you remember Acorn being any good in this respect?! In fact, if things suddenly got turned up to eleven, it would probably be quite unsettling.
  ^[ Log in to reply ]
 
Steffen Huber Message #125506, posted by hubersn at 15:10, 26/9/2023, in reply to message #125505
Member
Posts: 91
I think it's pretty simple for ROOL to control what ends up in the build. They are in control of what gets merged, so they don't even need to faff about with branches: they can simply only merge things which are important and/or safe enough to include in the release.
This is true, but a bad strategy if this phase takes a long time: you queue up merge requests, making merge conflicts much more likely. And you end up with a release that is not easily fixable. And you make the next publishable development version much more unstable because you introduce so many changes at once. Bad news for your testers.

All this could be handled much easier if you just do what the rest of the world does: branch before release, stabilize the branch, have an easily fixable state that you can patch indefinitely. And keep on developing the potentially unstable main branch.

Branching is possibly the only thing that is really easy and fast in Git. Strange to not use it.
  ^[ Log in to reply ]
 

The Icon Bar: News and features: Updated RISC OS Git client sent to beta testers