Git client?

Chris, I’d been hoping I’d see you post again. Any chance you could drop me a line at my rcomp or andrew at riscosdev emeil addresses please, as I don’t have your contact details.

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?

Possibly. I guess it’d depend on how much work the frontend has to do to do something useful – e.g. if I wanted to write a script in BASIC which does a simple action on a repository, would there be 10 lines of API glue or 100? Or, how much effort would it be to write a BASIC library to map the module interface into something BASIC friendly?

If the interface can be agreed on it would also in theory mean the two sides could run in parallel.

The only sensible starting point would be the libgit2 C API. If there are any APIs which modify global state/configuration then we’d need to add a ‘client ID’ to each SWI so that the state can be different for each client. And I suspect libgit2 has over 64 public functions, so we’d either need multiple SWI chunks, or a single LibGIt2_Op SWI (or exposed function table) which exposes everything. Care will also be needed for situations where libgit2 calls back into client code.

But on the whole it should look and feel as close as possible to the C API, because the libgit2 developers have almost certainly spent more time designing their API than we’ll spend designing anything we come up with :-)

But on the whole it should look and feel as close as possible to the C API, because the libgit2 developers have almost certainly spent more time designing their API than we’ll spend designing anything we come up with :-)

That’s never stopped the RISC OS world before :)

but yes having looked at the LibGit2 interface in more detail, it’s probably a lot of effort for little gain.

What might be useful for something like BASIC is it it presents an interface akin to OS_GBPB – one call to read the list of files, one to read chunks from a file.

Or, for the adventurous (and to make it easy to interface with anything), a GitFS image filing system?

Of course there are numerous issues (versions, change log, putting stuff back), that’ll need some thought as to how to do it best, but a simple way for an application to read would be a start.

Notice I’m tacitly agreeing with Chris. An API should be our API. Not because we can do it better, but because we are different enough that APIs that work well elsewhere may not be best suitable for RISC OS.

Something I feel quite strongly about is software that expects weird bastardised filenames that are an unholy mishmash between our style and POSIX, leading to confused stuff like SDFS::SomeDisc/$/My/Path/File.name or the like. As far as I’m concerned if it runs on RISC OS and neither presents nor copes with a regular normal file specifier, it’s incomplete. The application and/or the user shouldn’t need to rummage in documentation in order to figure out what the hell the file syntax is.

Add to this programs that are incapable of dealing with files until there is some sort of an extension. UnBZip2, I’m looking at you. Why must I suffix “/bz2” (or whatever it is) to the filename before it’ll recognise it?

So, yeah. Other people’s APIs may not necessarily work in an expected manner.

UnBZip2, I’m looking at you. Why must I suffix “/bz2” (or whatever it is) to the filename before it’ll recognise it?

I suspect that it’s something to do with making an associated /tar file, but I don’t really agree with that behaviour since it could just append /tar instead of removing the /bz2. Alternatively it could put the intermediate tar file in Scrap (with whatever name it likes) instead of cluttering up the current directory. But I digress…

Something I feel quite strongly about is software that expects weird bastardised filenames that are an unholy mishmash between our style and POSIX, leading to confused stuff like SDFS::SomeDisc/$/My/Path/File.name or the like. As far as I’m concerned if it runs on RISC OS and neither presents nor copes with a regular normal file specifier, it’s incomplete. The application and/or the user shouldn’t need to rummage in documentation in order to figure out what the hell the file syntax is.

Completely agree with this!

But it might not be a tar file that was bzip2ed, so it takes off the bz2 to get the original file name. The name before the bz2 is the information you have as to what sort of file has been bz2ed.

The risc os way would be to what squash does I guess, but that would mean storing the original file type somehow and wouldn’t work for files from other platforms.

OK, fair enough. As the app is called UnTarBZ2 I assumed that it required an underlying Tar :)

That would seem a responsible assumption :)