git 1.0.0 - release

Network operations are a little bit ropey, it seems. I’ve already mentioned that it was doing odd things to try to access CertData, but I’ve done some more tests, and it’s even more weird in what it’s doing.

Here’s the remote I’ve got configured:

*git remote --verbose
fake    <a href="http://localhost:80/foo.git">http://localhost:80/foo.git</a> (fetch)
fake    <a href="http://localhost:80/foo.git">http://localhost:80/foo.git</a> (push)

And I want to fetch from it with `git fetch fake`.
If I run it normally I just get back `fatal: Could not perform fetch`, which is unhelpful so I wanted to see where it was actually failing. I turned on file and internet debugging, to see what was happening (I also turned on Resolver debugging, but it doesn’t use the resolver module, as you’ll see, so that showed up nothing).

The full log can be found here: https://gitlab.gerph.org/snippets/19

Here’s a quick summary of what happened:

(the read catalogue info calls are performed twice – I’m not sure whether that’s something I’m doing or something that the git tool is doing, so I’m just treating the ‘read catalogue info with path’ + ‘read catalogue info’ operations as a single operation.

• Try to access System:Module.CryptRand
• Read catalogue info for _git.
• Read catalogue info for $.gittest.riscos-git._git (which is the directory I was using for the repo).
• Read catalogue info for $.gittest.riscos-git.git.git (a couple of times).
• Read catalogue info for $.gittest.riscos-git._git
• Read catalogue info for $.gittest.riscos-git._git.commondir
• Read catalogue info for $.gittest.riscos-git._git.HEAD
• Read catalogue info for $.gittest.riscos-git._git.objects
• Read catalogue info for $.gittest.riscos-git._git.refs
• Read catalogue info for $.gittest.riscos-git._git.gitdir
• Read catalogue info for $.etc.gitconfig
• Read catalogue info for $.gittest.riscos-git._git.gitconfig (8 times)
• Read catalogue info for $.gittest.riscos-git
• Read catalogue info for $.gittest.riscos-git._git.index (6 times)
• Read catalogue info for $.gittest.riscos-git._git.gitconfig (8 times)
• Read catalogue info for $.Internet.files.CertData
• Read catalogue info for InetDBase:resolv.conf
• Create a TCP socket
• Try to connect to 0.0.0.0 port 53
• Close the socket
• Do that create-connect-close again.
• Read catalogue info for InetDBase:hosts (2 times)
• Do that create-connect-close again.
• Read catalogue info for InetDBase:hosts (2 times)
• Report ‘fatal: Could not perform fetch’

In other debug (which I didn’t include here, because it’s crazy noisy) I had the system variables enabled and after trying to read the CertData, it does this (which could be inserted into the above description):

• Read catalogue info for $.Internet.files.CertData
• Lookup Inet$ResolverRetries (not present)
• Lookup Inet$ResolverDelay (not present)
• Lookup Inet$LocalDomain (‘gerph.org’)
• Read catalogue info for InetDbase:resolv.conf
• Lookup InetDBase$path (not present)
• Lookup Inet$Resolver (not present)
• Lookup Inet$SearchDomains (not present)
• Create TCP socket

So there’s a few things here:

• Even though we’re not using certificates, we try to find the directory, using a hardcoded path.
• We do a lot of operations on the same files (that’s actually pretty normal for unix-y tools, so … meh)
• “$.etc.gitconfig” should probably be a system resource accessed through a variable, rather than hard coded?
• Strange use of “InetDBase:resolv.conf”; I’m pretty sure that would have been “InetDBase:resolv/conf” if it existed at all.
• Should really be using Resolver, rather than trying to do everything itself.
• When it fails to find any hostent for the name, it should probably give up, rather than trying to connect to 0.0.0.0, which is going to fail.
• If it’s going to do it itself (which it shouldn’t, but as a point of order anyhow) hosts should be looked at /before/ going to the network – it takes precedence over network resolved addresses.

Yes you have caught most of the typical things that can go wrong in linux ports.
Firstly there is often a problem when using a RISC OS path variable for config files, because the program will tag on the file (or worse a directory for a later file) in unix style.
You can either convert the path to unix using getenv() or less work, use the established unix shell variable, and do the conversion from the system path to a unix path, and set GITCONFIG or whatever inside an Obey file in the finished application.
Also at the configuration stage you can use the —prefix to overide things like /etc
I have used . before, but the usefulness of using the pwd/csd could vary.
configure bitches about prefix paths it cant resolve, so it’s likely you have to patch the
makefile.in or makefile instead
Edit: to be complete, The fact that sometimes all that is needed is for the HOME variable to be set, and it will be used instead of /etc for configs.

The problem could run deeper with git if it is constantly changing paths.

Yes the other thing to be aware of is those <http:://blah.blah> which could be getting read as an empty variable, in the same way the CLI does.

I have a small c utilty called unixvar that I use from an obey file to construct a unixpath variable such as FETCHMAILHOME that the unix port supposedly looks up as $FETCHMAILHOME.
It does give you the flexibility to change things from a script, but the unixvar part could equally be done in the program, and if it is repeated a large number of times, (could be the case with git) probably preferrable. Basically a combination of getenv and converting dots to slashes, minding the disc name up to the $

I have a problem with adding a file. I have the following struture:

src
  main/c
  t

I can add the file src.t, but adding the file src.main/c does not add the file (command: git add src.main/c).

‘git status’ says that the file src.c.main is untracked. ‘git add src.c.main’ does not add the file.

Any suggestions?

Any progress on this since Kevin announced v1.0.0 in back in July 2020?
(And even that seems only available from the link at the top of the thread, as I could not find it by using the website).

The /git vs .git naming issue raised above seems to be a particular problem for me.

Thanks Kevin, I find this !git utilty incredibly useful, it is a real time saver for me.

Has this sunk without trace?

Has this sunk without trace?

I believe so. In 2021 Kevin said to me I’m likely not going to continue its development – largely because of the lack of much interest in it!

But I am very hopeful that the ROOL Git port will more than replace it before too long.

It’s a real pity :-(

I was very excited that it was working so well, and that even with a more limited set of operations it was still very functional. There were a few problems – some of my own making and some that were of more advanced things that wouldn’t have affected most people. Showing that a more limited functionality client was genuinely viable and useful was (I think) the encouragement to get my own git implementation to a point where it was useful.

So: have you got your own git implementation to a point where it’s useful, and will you release it to the world?

Looking at https://www.riscosopen.org/content/documents/bounties it would seem that there has been considerable progress with the Git client bounty – including a GUI.

Dave Higton asked…

So: have you got your own git implementation to a point where it’s useful, and will you release it to the world?

It handles pretty much anything you might need – so much so that it’s not a part of the ‘things that are a bit poor’ list in my head and is really just a ‘something that I can rely on if I need to’. Regular clones and pushes (with and without authentication), commits, merges, rebases, logging, submodules, diffs, stashing, tagging… they all appear to work just fine.

It has been available both in the RISC OS Build service (https://build.riscos.online/), and on https://shell.riscos.online, and if you request a copy of RISC OS Pyromaniac, for quite some time. According to the changelog, it’s been available since December 2022 (https://pyromaniac.riscos.online/pyromaniac/CHANGELOG.html#042-01-dec-2022). So yes, it’s been released to the world quite some time back.

A video showing how to use it to build things was produced back in January 2023 – https://presentations.riscos.online/using-git/index.html – to complement the other demonstrations of how you use git in other environments.

A small demo of building with RISC OS incorporates a tiny bit of checking out with git – https://presentations.riscos.online/live/building-beebit.html

There were also a number of posts on twitter about it back then as well, of which …

27 Nov 2022

After some discussion of git in a RISC OS meeting this evening, I dusted off the old Pyromaniac Git client that I wrote in mid 2020. With a little bit of merge-magic, the branch is still working. Spotted a few bugs, but it works quite nicely.

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

26 Dec 2022

In RISC OS Pyromaniac the Git integration can now request that the authentication details be filled in through an implementation. This means that in different environments you can be prompted differently. In the WxWidgets implementation, that means a host dialogue box.

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

27 Dec 2022

Whilst trying to merge my changes for RISC OS Pyromaniac’s ‘askpass’ integration, I found that I’d missed one of the switches. I added the switch, and then thought it’d make a nice video demonstration of committing the change inside RISC OS, and then doing the merge. So I did.

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

And of course the behaviour of the module is documented on the website as well – https://pyromaniac.riscos.online/pyromaniac/prm/programmers/pyromaniacgit.html

There’s simple help in the system as well…

*help git
==> Help on keyword 'Git' (PyromaniacGit)
Interface to the host 'git' command. This command must be supplied a command 
which many different parameters. More information on the options can be found 
through the help command:

*Git help - lists the available commands.
*Git help <command> - lists options for a command.

The operation of the git command is based on that of the host system. Whilst 
the interface has many limitations, it should be able to be used in a similar 
way to the standard version. Filenames should be able to be specified in RISC 
OS format and will be translated to the host format.

To function, many of the environment variables from the original system have 
been mapped to a form more like the manner that RISC OS functions. These 
variables and their translation are described in '*Help GitVariables'.

For more information on the meaning of the options for commands, please refer 
to the standard documentation (<a href="https://git-scm.com/docs">https://git-scm.com/docs</a>).

Commands:
    add               Add file contents to the index
    annotate          Annotate file lines with commit information
    blame             Show what revision and author last modified each line of a file
    branch            List, create, or delete branches
    checkout          Switch branches or restore working tree files
    cherry-pick       Apply the changes introduced by some existing commits
    clean             Remove untracked files from the working tree
    clone             Clone a repository into a new directory
    commit            Record changes to the repository
    describe          Give an object a human readable name based on an available ref
    diff              Show changes between commits, commit and working tree, etc
    fetch             Fetch from another repository or a local branch
    grep              Print lines matching a pattern
    help              Display help for a given command
    init              Create an empty Git repository or reinitialize an existing one
    log               Show commit logs
    merge             Join two or more development histories together
    mv                Move or rename a file or directory
    pull              Fetch from and integrate with another repository or a local branch
    push              Push to a remote repository
    rebase            Reapply commits on top of another base tip
    reflog            Manage reflog information
    remote            Manage set of tracked repositories
    reset             Reset current HEAD to the specified state
    restore           Restore working tree files
    rev-parse         Pick out and massage parameters
    rm                Remove files from the working tree and from the index
    shortlog          Summarize 'git log' output
    show              Show various types of objects
    stash             Stash the changes in a dirty working directory away
    status            Show the working tree status
    switch            Switch branches
    tag               Create, list, and delete tags on objects
    version           Report the version of git on the host and RISC OS system

Syntax: *Git <command> [<options>]

According to the changelog, it’s been available since December 2022

And now it’s being mentioned in the place where we hang out. ;)

There were also a number of posts on twitter about it back then as well

Twitter is worse than useless these days. People should stop relying on it as an information source (or, worse, their only source of contact).
Found an account (all the gerphs didn’t appear to be you) and was instantly redirected to…

https://twitter.com/i/flow/login?redirect_after_login=%2Fropyromaniac

So that’s a big nope from me.

Just curiosity makes me ask which of the links presented is the one where an interested, potential, user just does their normal click here to download and gets a zip file with something they can:

1. read the readme (if required)
2. and install the application
3. start using for simple tasks, then progress through levels of use.

Steve Pampling wrote:

Just curiosity makes me ask which of the links presented is the one where an interested, potential, user just does their normal click here to download and gets a zip file with something they can…

For RISC OS Pyromaniac, as I have repeatedly stated, you drop me an email and you can have a copy of Pyromaniac to run locally. Pyromaniac comes with lots of documentation about how to use it, but until anyone does so, I don’t know if that’s useful. Feel free to drop me an email. But the cloud services are available right now.

• If you want to use the cloud services, you use them on the Web like any other cloud services. Instructions on using the build service are available on the front page of build.riscos.online (https://build.riscos.online/) if you want to just try it out with a web interface.
• If you want to use the build service API to access it, the documentation is linked from the menu on the site (https://build.riscos.online/api.html).
• If you want to use the build service API within GitHub or GitLab installations, information is linked from the menu on the site (https://build.riscos.online/ci-build.html)
• If you want examples of using the build service API within GitHub, see the `riscos-ci` topic in GitHub.
• If you want to use shell.riscos.online in general, information on how to use it there is https://shell.riscos.online/ and the usage of RISC OS is… well, pretty much every where on this site – it IS RISC OS. Of course there is also online documentation through `Help` and `Git help` as well.
• The guide to explicitly using git with shell.riscos.online is the link I posted about the git with RISC OS… https://presentations.riscos.online/using-git/index.html

Rick Murray wrote:

And now it’s being mentioned in the place where we hang out. ;)

I’m mentioning it now because it’s a core part of Pyromaniac as a pretty functional system, and in reference to the fact that Kevin’s git was the inspiration to get things moving. It has been mentioned a few times at ROUGOL chats I believe, and as it was just part of general development. How to use it was part of the video I mentioned previously, announced by Paolo – https://www.riscosopen.org/forum/forums/1/topics/17687 back in January last year.

Twitter is worse than useless these days. People should stop relying on it as an information source (or, worse, their only source of contact).

Opinion is cheap. Since I neither rely on it as an information source, or as a point of contact, your comment is entirely irrelevant.

For RISC OS Pyromaniac, as I have repeatedly stated, you drop me an email and you can have a copy of Pyromaniac to run locally.

I can confirm Charles message. I have an happy Pyromaniac running on my Mac M1. All I had to do was, asking him :)