git 1.0.0 - release

Well. Did I bite off more than I can chew…

So anyway. This is it. Might as well start here – can’t procrastinate any longer! I’m officially releasing git 1.0.0 to all of you good folk in the RISC OS community. It is by no means finished (although by comparison, there’s been a team of 20+ developers on git for the last 15 years, and they’re still not finished…)

The link I’m offering here is a link to a RISC OS Zip file that should download and unpack more easily than the alpha version I offered a while back. It also includes a PDF User Guide. Grab it. Have a play with it. Learn about git.

Ultimately, I’d like to appreciate – more than anything else – whether what I’m doing is worthwhile for people: is it (by and large!) working, do people want me to continue, what’s working, what’s broken, what would people like to see next, etc.

And that’s kind of it, really. I can continue to faff and talk, but damn it here it is. Hopefully it’s helpful to some of you and maybe with the right feedback I can continue to take the helm for the community on this (if you’ll have me).

So without further ado, here’s a !NetSurf compatible link to get the v1.0.0 release direct on RISC OS:

http://www.abbeycatuk.info/wp-content/uploads/2020/07/git-v1-0-0.zip

And as a bit of a postscript, if anyone is interested Linus gave a talk years ago on git and it’s quite illuminating: https://www.youtube.com/watch?v=4XpnKHJAok8

E&OE! :-)

It doesn’t work for me. I note the executable is an E1F file do I need something to run those files?

I’ve updated the Zip file so that the git executable has been converted to an Asbolute file (rather than an ELF executable). I’ve just refreshed my local system here, redownloaded it, installed it and used it to clone a repo so that looks like it might be more palatable to non-ELF setups. Let me know if that helps.

You will of course need to remove any existing download you made, and perform a complete fresh download of this newer version to confirm if things have improved.

On a brief read of the PDF documentation… why does this filetypes metadata configuration exist? I’m sure it made sense to you at the time, and I think it’s quite cute in its own way, but it’s going to be utterly impractical to interwork with other clients. If you cannot see the metadata in a non-RISC OS client, it’s going to be lost, committed wrongly, or otherwise get broken handling if you work with a different client.

The NFS filename mapping format exists, and has been used for quite some years. It is the defacto standard way of representing files on a non-RISC OS system. It is used by NFS filesystems and explicitly supported by the zip file format. It has an encoding that works for just bare filetypes, and for explicit load/exec files. It means that you can create files on non-RISC OS systems which are extractable on RISC OS systems.

The ‘filetypes’ method you’ve created is essentially creating a niche that is only going to be used by the RISC OS client, and is going to make interworking more difficult. When the ,xxx / ,llllllll,eeeeeeee format is usable for the types, and more obvious what is going on, you’re going to find that most people will use that format anyhow, and trying to support an additional format is going to cause more support issues and confusion for users.

If you wish to continue using it, consider that the mappings table that you’re supplying also introduces an extra degree of confusion which will mean that the operation of the filetype mappings will change from user to user, depending on how they have configured their application.

Personally, I’d suggest ditching any specialised filetype handling through metadata, and focus on just handling it within the filenames. That way, the user does what they need to do and the ‘magic’ is within git, not within part of the user’s workflow (inserting additional git filetype operations, or documenting updates to a mappings file that users will have to use within their repository). And it reduces the number of mechanisms you have to support.

Little bit of faffing later (didn’t have SharedUnixLibrary loaded, and it assumes that the desktop exists – craziness! :-) )…

*git -h
Unknown option: --h
usage: git [--version] <command> [<args>]
 The most commonly used git commands are:
   add       Add file contents to the index
   branch    List, create, or delete branches
   checkout  Checkout a branch or paths to the working tree
   clone     Clone a repository into a new directory
   commit    Record changes to the repository
   fetch     Download objects and refs from another repository
   filetype  Set or apply RISC OS filetypes
   init      Create an empty Git repository or reinitialize an existing one
   log       Show commit logs
   merge     Join two or more development histories together
   pull      Fetch from and integrate with another repository or a local branch
   push      Update remote refs along with associated objects
   rm        Remove files from the working tree and from the index
   status    Show the working tree status
usage: git [--version] <command> [<args>]
 The most commonly used git commands are:
   add       Add file contents to the index
   branch    List, create, or delete branches
   checkout  Checkout a branch or paths to the working tree
   clone     Clone a repository into a new directory
   commit    Record changes to the repository
   fetch     Download objects and refs from another repository
   filetype  Set or apply RISC OS filetypes
   init      Create an empty Git repository or reinitialize an existing one
   log       Show commit logs
   merge     Join two or more development histories together
   pull      Fetch from and integrate with another repository or a local branch
   push      Update remote refs along with associated objects
   rm        Remove files from the working tree and from the index
   status    Show the working tree status

Is that something I’ve done wrong that makes it respond with two sets of usage information? It’s entirely possible that this is something odd with my OS.

I tried to clone a repository:

Supervisor

*setupgit
*git clone <a href="http://gitlab.gerph.org/justin/ddeutilsjf.git">http://gitlab.gerph.org/justin/ddeutilsjf.git</a>
Cloning into 'ddeutilsjf'...
fatal: clone could not clone
*

Turning on SWI debugging I see that:

• SWI &41981 is called, and then a moment later it issues a RMEnsure: “RMEnsure CryptRandom 0.12 RMLoad System:Modules.CryptRand” (this is not printed out so it wasn’t clear when it was initially used that this was required). Maybe just an update to the documentation and an error report when it’s not found but is needed.
• It’s then trying to look up some files in “<Boot$Dir>.Resources.!Internet.files.CertData”. There’s no report in the output that the error came from a HTTPS URL (my server’s doing automatic redirection). I guess that’s probably understandable, and I’ll have to source some suitable information. However, that usage is clearly wrong. Files in the Internet resource should be accessed as InetDBase:… as it should never be assumed where that resource will live.
• SWIs &4f701 and &4f709 are being called (they don’t exist here); I don’t know what those are… they might even be an artifact of my system and nothing to do with the git tool.

I see you’re using ‘_git’ as the storage directory. That’s going to mean that git repositories checked out on other systems, which use the NFS file mapping format (which I suspect to be most) will not interwork with the git repositories checked out by this tool. If the name were ‘/git’ then all would be well. In the standard git tooling, you would set GIT_DIR to change this name, but I only see ‘git$heap’ being read explicitly (although it does appear to enumerate all the environment variables, so it’s possible that a separate lookup for such things is taking place).

The global gitconfig file is inside the application; that’s not really good, because it means that when you replace the application, you delete the global configuration you’ve set up. It should really be read from Choices:Git.Config (or something similar).

So I tried creating a new repository with a file in and here’s the log of what happened… ‘cos it’s really quite exciting (to me it is anyhow)…

*dir newrepo
*git init
Initialized empty Git repository in @
*.
Dir. $.newrepo Option 02 (run)
CSD  NoFileSystem:$.newrepo
Lib. NoFileSystem:$
URD  NoFileSystem:$
_git DWR/WR  
*build myfile
     1 This is my file!
     2 
*settype myfile text
*ex
Dir. $.newrepo Option 02 (run)
CSD  NoFileSystem:$.newrepo
Lib. NoFileSystem:$
URD  NoFileSystem:$
_git   DWR/WR Directory   01:13:15 13-Jul-2020     0 bytes
myfile  WR/WR Text        01:13:46 13-Jul-2020    17 bytes
*git add myfile
*git commit -m "my commit message"
error: unknown option 'm'
usage: git commit [--message <message>] [--file <pathname>]
*git commit --message "my commit message"
fatal: commit requires user.name and user.email config settings
*| out of band addition of the user.name and user.email inside the git application.
*git commit --message "my commit message"
  144924: <WATCH> READ  [&00000010] = &00000000  (word)
            r0  = &00000000, r1  = &004e8e9c, r2  = &00000001, r3  = &0018d838
            r4  = &00000000, r5  = &004e8fa8, r6  = &00000000, r7  = &ffffffff
            r8  = &a45efc40, r9  = &00193df0, r10 = &004e8208, r11 = &004e8e74
            r12 = &004e8e78, sp  = &004e8e3c, lr  = &00143bec, pc  = &00144924
            CPSR= &20000010 : USR-32 ARM fi ae qvCzn
          Locations:
            pc is DA 'Application Space': Function __cvt_broken_time+&14
            lr is DA 'Application Space': Function mktime+&24
          Executing code block (pc is not exact):
                144924: SUB     sp, sp, #&1c
                144928: LDR     r5, [r0, #&10]
                14492c: ADD     r2, r0, #8
                144930: LDMIA   r2, {r2, r3}
                144934: LDR     lr, [r0]
                144938: LDR     r12, [r0, #4]
                14493c: MOV     r4, r0
                144940: MOV     r6, r1
                144944: MOV     r0, r5
                144948: MOV     r1, #&c                   ; #12
                14494c: MOV     r7, #0
                144950: STR     r2, [sp, #&c]
                144954: STMIA   sp, {r7, lr}
                144958: STR     r12, [sp, #8]
                14495c: STR     r3, [sp, #&10]
                144960: BL      &001271A0
[SNIP - other watchpoints fired]
*git log
commit fc9732a81e7847e66a00097d8f885f886276cccd
Author: Charles Ferguson <<a href="mailto:gerph@gerph.org">gerph@gerph.org</a>>
[SNIP - more watchpoints]
Date:    t[^X/24:32,43,48,48,48,48,13,10]
    my

*

So… the watchpoints firing are almost certainly something broken in my implementation of TerritoryManager, and I can cope with that. The commit command not supporting the ‘-m’ switch is something you mentioned in the docs, and I’d forgotten / muscle memory made me do it. ¹

The `git log` command seems to have truncated the message. I don’t know if that’s something I broke in my OS, or something that went wrong elsewhere, and again the date has got upset, related to those watchpoints firing for zero page (I’ll fix that later).

The disc I’m using is on MacOS, and so on there, I can see what the repository contains… which gives me this output:

charles@laputa ~/Doc/Win/RPC/hos/newrepo> ls
_git   myfile
charles@laputa ~/Doc/Win/RPC/hos/newrepo> ln -s _git .git
charles@laputa ~/Doc/Win/RPC/hos/newrepo (master⊗)> git status
On branch master
Untracked files:
  (use "git add <file>..." to include in what will be committed)
	_git/

nothing added to commit but untracked files present (use "git add" to track)
charles@laputa ~/Doc/Win/RPC/hos/newrepo (master⊗)> git log
commit fc9732a81e7847e66a00097d8f885f886276cccd (HEAD -> master)
Author: Charles Ferguson <<a href="mailto:gerph@gerph.org">gerph@gerph.org</a>>
Date:   Fri Jan 23 00:32:54 2071 +44294416

    my
charles@laputa ~/Doc/Win/RPC/hos/newrepo (master⊗)> 

But, it’s worked… and that truncation is there, but it’s not complaining about it, so clearly the records in git are valid.

I thought I’d try a git gc and a git fsck to see if the repo was valid:

charles@laputa ~/Doc/Win/RPC/hos/newrepo (master⊗)> git gc
Enumerating objects: 3, done.
Counting objects: 100% (3/3), done.
Writing objects: 100% (3/3), done.
Total 3 (delta 0), reused 0 (delta 0)
charles@laputa ~/Doc/Win/RPC/hos/newrepo (master⊗)> git fsck
Checking object directories: 100% (256/256), done.
error in commit fc9732a81e7847e66a00097d8f885f886276cccd: badTimezone: invalid author/committer line - bad time zone
Checking objects: 100% (3/3), done.

I chalk that up as a win. I’ve caused the bad timezone, but otherwise it’s happy.

So yeah, I’m pretty impressed with that, filename convention comments notwithstanding. It’s working, at least on the basic level of being able to add files. And I now have bugs to fix in my OS.

Well done :-)

¹ Aside: I had a command line tool called ‘ee’ which was intended to be used for exactly this sort of thing – being able to write log messages in SCMs. It was intended to be used when you’re in the TaskWindow to be able to use the External Editor (Zap in my case, but StrongEd and others support the protocol too) so that you can edit things in an external tool. I’ve not 32bitted it, but it’s one of the examples on JFPatch-as-a-service and would probably be simple to do. I’ve also got a port of ‘pico’ which could be used as a GIT_EDITOR (I guess, <Git$Editor> in RISC OS parlance). Do you intend to support the launching of an editor for commit messages? (yes, you should :-) single line commit messages should be shot on sight)

single line commit messages should be shot on sight

Hear! Hear!

The number of Android apps that claim their changes are “Bug fixes and performance enhancements” is ridiculous. It’s utterly lazy and doesn’t really give one incentive to want to update. Especially given there’s no concept of rollback and sometimes things get worse not better.
[on my freebie tablet, for example, Google Docs worked great last summer where I rolled off ~90 pages of a fiction story; but it’s been getting progressively slower to the point where the OS pops up “all isn’t responding” messages several times at startup; and there’s no cool new functionality to explain the change…oh, and in print preview mode, a 1GHz 4 core chip is no longer able to keep up with a regular speed typist – what the hell?]

Thanks Kevin it is working now.

First impressions is that it is not as friendly as the linux version which gives more hints on what to do next and git help command is rather terse. git init worked git reset didn’t. Not comfortable with the file naming scheme but it probably wouldn’t be a deal breaker if the rest was working reliably.

I had a command line tool called ‘ee’ which was intended to be used for exactly this sort of thing

in the cvs distribution I added !cvs.editor which is set up as cvs$editor which launches stronged in my case.

InetDBase: -and – It should really be read from Choices:Git.Config

I’m pretty sure (colon) Paths do not currently work using unixlib, System variables like <InetDBase$Path> are fine.
Theo knows the details. I have had to replace the use of Choices: in a unixlib recipe file with an alternative, leads to me believe they might have worked once?

The number of Android apps that claim their changes are “Bug fixes and performance enhancements” is ridiculous. It’s utterly lazy and doesn’t really give one incentive to want to update. Especially given there’s no concept of rollback and sometimes things get worse not better.

It’s the same on iOS. My policy is not to install any update that doesn’t have a descriptive change log. This results in a double-digit red badge on the App Store icon :)

a 1GHz 4 core chip is no longer able to keep up with a regular speed typist

https://danluu.com/input-lag/

Input lag – taken to Aldershot

I’m pretty sure (colon) Paths do not currently work using unixlib, System variables like <InetDBase$Path> are fine. Theo knows the details. I have had to replace the use of Choices: in a unixlib recipe file with an alternative, leads to me believe they might have worked once?

I find that difficult to believe, though. A C library that doesn’t allow access to the filesystem wouldn’t be fit for purpose. I would expect that you can still access path variables yourself by expanding them, but … that would be nuts. And in this case, the git tool cannot be trying to expand the InetDbase$Path itself, because it’s not set, and nothing on the system refers to !Boot.

I’ve found what happened with the watchpoints firing for zero-page access – I should have been paying more attention last night because it was pretty obvious in the log.

Try full trace around the watchpoints shows:

  152a60: SWI     XOS_Word
          => r0  = &0000000e         14  constant 14
  144cf0: SWI     XTerritory_ConvertTimeToUTCOrdinals
          => r1  = &004e8e98    5148312  pointer to date_and_time
                   [&8f529d78, &00000058, &001926f8, &004e8fa8]
             r2  = &004e8e5c    5148252  pointer to ordinals
                   [&4a417266, &00005f0c, &1266f400, &004e8ef0]
          <= Error returned: (&000001e6) SWI &43049 (Territory_ConvertTimeToUTCOrdinals) not known
  144924: <WATCH> READ  [&00000010] = &00000000  (word)
            r0  = &00000000, r1  = &004e8e9c, r2  = &00000001, r3  = &0018d838
            r4  = &00000000, r5  = &004e8fa8, r6  = &00000000, r7  = &ffffffff
            r8  = &a488d540, r9  = &00193de8, r10 = &004e8208, r11 = &004e8e74
            r12 = &004e8e78, sp  = &004e8e3c, lr  = &00143bec, pc  = &00144924
            CPSR= &20000010 : USR-32 ARM fi ae qvCzn
          Locations:
            pc is DA 'Application Space': Function __cvt_broken_time+&14
            lr is DA 'Application Space': Function mktime+&24

So it’s not that Territory_ConvertTimeToUTCOrdinals is implemented wrongly; it’s that it’s not there. That causes the tool to fail (well, actually because zero-page is there it doesn’t crash, but it shouldn’t be accessing that location). Whilst I will get that implemented, the tool shouldn’t crash when a SWI reports an error. It could have just run out of memory.

and nothing on the system refers to !Boot.

yeah !Boot doesn’t mean much, sometimes the System Boot variable (forget it exactly) is needed to identify /this/ filesystem.

I find that difficult to believe, though

Just a quick note… with Territory_ConvertTimeToUTCOrdinals and Territory_ConvertOrdinalsToTime implemented, the zero-page watches don’t trigger and I get a sensible git log produced:

*git log
commit 33c67cab02207c1afb172633c819f334bdbc56cc
Author: Charles Ferguson <<a href="mailto:gerph@gerph.org">gerph@gerph.org</a>>
Date:   Mon Jul 13 13:28:38 2020 +0000

    whee

commit c2f9337407454da8c0a72a8f06c79f6430669599
Author: Charles Ferguson <<a href="mailto:gerph@gerph.org">gerph@gerph.org</a>>
Date:   Mon Jul 13 14:05:23 2020 +0100

    another

And the problem with only taking the first word of the commit message is something in my alias parsing, it appears. However, it does show up a bug in the git command parser:

If you use `git commit —message my message`, it will commit with the message `my` and ignore the word `message` without error. It should probably report that as an error, and not perform the commit.

Well done on the release of version 1.0.0!

*git --version
git version 1.0.0
  - libgit2 version 0.28.4
  - mbedTLS version 2.16.3 

git clone https://github.com/zedshaw/learn-c-the-hard-way-lectures.git clthw

Thank you…

Thanks for the feedback so far folk. (Been away from RISC OS for 25 years so picking git was probably a bit over ambitious!) I’ll be taking some of these points on board for subsequent patches and updates. As for git reset, firstly if you call “git reset” that’ll do a mixed reset by default (as canonical git does). You can specify —soft or —mixed or —hard. But do note I’ve spotted an unusual problem with this functionality when git reset —hard is called – I’m investigating as it is causing problems on one particular repo that I’m using for testing (others seem to work fine), so “git reset —hard” is probably best avoided where possible in the meantime. YMMV.

I’m pretty sure (colon) Paths do not currently work using unixlib, System variables like <InetDBase$Path> are fine. Theo knows the details. I have had to replace the use of Choices: in a unixlib recipe file with an alternative, leads to me believe they might have worked once?

I find that difficult to believe, though. A C library that doesn’t allow access to the filesystem wouldn’t be fit for purpose. I would expect that you can still access path variables yourself by expanding them, but … that would be nuts. And in this case, the git tool cannot be trying to expand the InetDbase$Path itself, because it’s not set, and nothing on the system refers to !Boot.

I confess I don’t fully understand the logic in riscosify.c (and unixify.c ) but just to note that filename translation is one of the more complex parts of UnixLib. The problem is that a path like git@github.com:user/project.git can have entirely different and valid meanings on RISC OS and on Unix, and sometimes those meanings can both be valid and ambiguous. For a git client on Unix, it means connecting to GitHub via SSH. For RISC OS, it can be interpreted as <git@github.com$Path>.user/project.git which strangely won’t exist.

This translation is what makes using existing codebases which are built for Unix paths feasible (probably including libgit although I haven’t looked at that). Without it you’d have to tear them apart to retrofit RISC OS path handling and be left with an ageing unmaintainable heap of code (since you’re unlikely to do the same tearing apart for every upstream release).

Additionally, UnixLib also has to deal with cross-compiling; when you #include “DeskLib:Core.h” and try and cross compile that on Linux, it needs to translate DeskLib: to something that makes sense on Linux.

Unfortunately the translation has been added piecemeal over the years and there isn’t a canonical description of what should translate to what. The best is the riscosify.c test code which has a large number of examples (also testunixify.c ). Those give you a flavour of how complicated this is and all the cases it covers.

Looking at the code I can’t see anything doing path expansion (so InetDBase: should never become <InetDBase$Path> or Choices:whatever) so not sure what’s going on there. And I don’t see a problem with Mypath:File as far as Unixlib is concerned.

Filename translation is one of the tricky parts of writing a client, and why my brief attempts at porting the original git were unsuccessful.

On a brief read of the PDF documentation… why does this filetypes metadata configuration exist? I’m sure it made sense to you at the time, and I think it’s quite cute in its own way, but it’s going to be utterly impractical to interwork with other clients. If you cannot see the metadata in a non-RISC OS client, it’s going to be lost, committed wrongly, or otherwise get broken handling if you work with a different client.

I think this depends on the use case. For a RISC OS software development project, I can see ,xxx filetypes being fine – !Run,feb is easily understood as an Obey file, and nobody wants to use that in another way. I think that should be the canonical naming in that case.

When it’s a bigger non-RISC OS upstream project I can see the use case for wanting to assign RISC OS filetypes to things without renaming things in the existing repo. No upstream is going to accept commits where you rename things to ,xxx just because you happen to be using RISC OS. So I can see the merit of a local translation.

However the thing here is that non-RISC OS upstream is likely using file extensions instead – so it’s example.pdf. You shouldn’t need to rename that to example.pdf,adf but then you shouldn’t need any custom mapping at all – the extension should be enough to figure out the filetype.

That leaves a niche where there’s either no extension or the extension is incorrect. I can see the ‘git filetype’ being useful only in that limited case.

[A thought occurs to me though that the .gitattributes file is likely to still cause pollution in your commits to upstream projects. So having it doesn’t actually resolve that use case of wanting filetypes for your private RISC OS use but interacting with a larger project. Will the client operate without committing the .gitattributes?]

The canonical git client suffers from inconsistency in the way it works. It is a matter of debate whether these idiosyncrasies should be ported as well. (from the manual)

Since you’ve called your tool ‘git’, I’d suggest you should mirror the mainstream git client’s behaviour. Any time someone googles for ‘how do I do X in git’ they will be told how the main client does it. Your being different for the sake of it will just be an annoyance. If you want to make an extra interface called ‘tidygit’ or something that’s fine (maybe someone has already designed a nicer CLI UI for it, it’s possible). But don’t offer something called ‘git’ and then behave different from the git everyone is used to. Also, all the scripts. Makefiles, etc out there are written for the mainstream client’s options.

(The same goes for version numbering: when a guide says ‘you need git 1.8.x for this feature’ and the RISC OS client is 1.0.0 it’s confusing. I’d suggest picking a different format like RO1.0.0 to make clear it’s not directly comparable)

Well. Did I bite off more than I can chew…

Been away from RISC OS for 25 years so picking git was probably a bit over ambitious!

Oh, I certainly know that feeling Kevin! :D It’s better to take on a challenge than to be bored though.
Keep up the great work!

the logic in riscosify.c (and unixify.c )

and being recipe files there is a lengthy ./build-world to do to test any changes you may want to try, sometimes only to find you left out a ; (-:

so InetDBase: should never become <InetDBase$Path>

The combination of this site/or my network? being slow today and Netsurf is causing error/incomplete download. however pressing retry will obviously post again as well, hence the duplicate postings. (now edited from Linux)

mypath:file

Have you got a unixlib binary other than gcc that will find such a file?

Regarding the use of _git as the GIT_DIR…

I suggested that GIT_DIR could be used to override this (in RISC OS that’d be Git$GitDir I think, because Git$Dir is for the Git tool resources, and we don’t use underscores). This is not entirely true .

If you set GIT_DIR to anything other than .git, the regular git assumes that you want a bare repository when you do a `git init`. You should be able to override this by setting the configuration option `core.bare = false` according to the documentation in git-config. But this does not work – you still get a bare repository.

To create a regular git repository with the name _git for the repo data with the regular git command you use the undocumented `—no-bare` switch to `git init`. For example:

env GIT_DIR=_git git init --no-bare

It also seems that that creates the _git.config file with a worktree entry in it; which doesn’t work with Kevin’s version if it’s not a file on the filesystem (which it won’t be if it was created on a different system, with completely different filesystems), so that line needs to be removed as well.

So that makes it just a little more fun if you’re wanting to interwork between the clients.

Whee! Bug in interworking (although it might just be in how the pack files are handled).

I’ve reduced this as much as I can. The context I’ve got is a RISC OS with the filesystem shared with that used by the regular git client, with the regular git client’s environment configured to use GIT_DIR=_git so that it works as you would expect.

The basic sequence of commands was thus:

Supervisor

*setupgit
*git init
Initialized empty Git repository in @
*build foo
     1 hello!
     2 
*git add foo
*git commit --message "test message"
*git log
commit 934a913c4ae5034c28e1d699d7922204a1e86f3b
Author: Charles Ferguson <<a href="mailto:gerph@gerph.org">gerph@gerph.org</a>>
Date:   Sun Jul 19 11:22:50 2020 +0100

    test message

*


<on host filesystem issue `env GIT_DIR=_git git gc`>


*git log

<watchpoints for zero page triggered>

The watchpoint logs are a little long for this forum, so I’ve posted them in full here: https://gitlab.gerph.org/snippets/18

However, including just one shouldn’t hurt (the others are similar and may stem from the same root cause):

   74aa8: <WATCH> READ  [&00000000] = &00000000  (word)
            r0  = &00000000, r1  = &00193af0, r2  = &0018e018, r3  = &004e8c98
            r4  = &001873b4, r5  = &004e8cf0, r6  = &00193a88, r7  = &00000053
            r8  = &00000058, r9  = &00193428, r10 = &004e8208, r11 = &004e8cbc
            r12 = &004e8cc0, sp  = &004e8c8c, lr  = &0004a338, pc  = &00074aa8
            CPSR= &20000010 : USR-32 ARM fi ae qvCzn
          Locations:
            pc is DA 'Application Space': Function git_strmap_lookup_index+&14
            lr is DA 'Application Space': Function git_mwindow_get_pack+&44
          C backtrace:
               74aa8 function git_strmap_lookup_index
               4a338 function git_mwindow_get_pack
               52020 function packfile_load__cb
               5b354 function git_path_direach
               51e7c function pack_backend__refresh
               52288 function git_odb_backend_pack
               4d1c8 function git_odb__add_default_backends
               6ba38 function git_repository_odb__weakptr
               6bb98 function git_repository_odb
               721c0 function git_revwalk_new
                ae20 function push_rev
                b394 function cli_log
                8444 function main
          Executing code block (pc is not exact):
               74aa8: SUB     sp, sp, #&10
               74aac: LDR     r8, [r0]
               74ab0: CMP     r8, #0
               74ab4: MOV     r9, r0
               74ab8: MOV     r7, r1
               74abc: BEQ     &00074B44
               74ac0: LDRB    r3, [r1]
               74ac4: CMP     r3, #0
               74ac8: SUB     r12, r8, #1
               74acc: BNE     &00074B4C
               74ad0: LDR     r2, [r9, #&10]
               74ad4: MOV     r4, r3
               74ad8: MOV     r5, #0
               74adc: MOV     r1, r4, LSR #4
               74ae0: LDR     r0, [r2, r1, LSL #2]
               74ae4: AND     r6, r4, #&f

All the reports are within the calls from git_mwindow_get_pack to git_strmap_* functions, so it’s possible that it’s actually the git_mwindow_get_pack function that’s being passed a NULL that’s being dereferenced. The read that I believe is failing is at &74aac; LDR r8, [r0], where the r0 value is NULL.

In reply to Theo…

The problem is that a path like git@github.com:user/project.git can have entirely different and valid meanings on RISC OS and on Unix, and sometimes those meanings can both be valid and ambiguous. For a git client on Unix, it means connecting to GitHub via SSH. For RISC OS, it can be interpreted as <git@github.com$Path>.user/project.git which strangely won’t exist.

This is a spurious reasoning. In a git client it means connecting to GitHub via SSH because the git client recognists that as a format which, in the context of a repository reference, is treated as a git path. The directory `git@github.com:user` could exist, and the git client allows for the non-ambiguous form to be specified by using a `file:///` prefixed name, or explicitly anchoring with a root specification, or by using the `—local` switch to be explicit that the repository name given is local to the machine and the special syntax for the remote repositories should not apply.

The git client, by allowing the ambiguity, has needed to introduce a mechanism to resolve it, which it does. And by doing so, the git client itself deals with this problem – the case of git@github.com:user/project.git will be handled within the git client and never make its way to the filesystem handling code. Thus it is a non-issue for how you interpret such paths within a C library. On a RISC OS system, you would be more likely to encounter this ‘git aware’ code tripping up the git system when you give it a RISC OS filename, but using the get-out option of —local, you avoid that problem, and all other cases are handled in the client.

What I’m saying is that such a specification is not an instance where filesystem ambiguity should come in – such paths should never reach the filesystem code.