Git clone path collision on case-insensitive filesystems

[camall3n]

Cloning the project results in a path collision on filesystems that are case-insensitive (like MacOS, by default). This seems to be due to the fact that gym_miniworld/textures/chars/ contains filenames that differ only by their capitalization.

One workaround that I've discovered is to create a case-sensitive disk image, mount it, and clone the repository there instead. (See here for more information.)

$ git clone https://github.com/maximecb/gym-miniworld.git
Cloning into 'gym-miniworld'...
remote: Enumerating objects: 71, done.
remote: Counting objects: 100% (71/71), done.
remote: Compressing objects: 100% (57/57), done.
remote: Total 6981 (delta 39), reused 31 (delta 14), pack-reused 6910
Receiving objects: 100% (6981/6981), 136.82 MiB | 11.97 MiB/s, done.
Resolving deltas: 100% (1920/1920), done.
Updating files: 100% (3458/3458), done.
warning: the following paths have collided (e.g. case-sensitive paths
on a case-insensitive filesystem) and only one from the same
colliding group is in the working tree:

  'gym_miniworld/textures/chars/ch_A_1.png'
  'gym_miniworld/textures/chars/ch_a_1.png'
  'gym_miniworld/textures/chars/ch_A_10.png'
  'gym_miniworld/textures/chars/ch_a_10.png'
  'gym_miniworld/textures/chars/ch_A_11.png'
  'gym_miniworld/textures/chars/ch_a_11.png'
[...]
  'gym_miniworld/textures/chars/ch_Z_8.png'
  'gym_miniworld/textures/chars/ch_z_8.png'
  'gym_miniworld/textures/chars/ch_Z_9.png'
  'gym_miniworld/textures/chars/ch_z_9.png'

[maximecb]

Hm. That seems like a problem we should fix.

Maybe we could rename the characters based on the hex code of the ascii char, like ch_A.png => ch_0x41.png

Would need to adjust this script: https://github.com/maximecb/gym-miniworld/blob/master/scripts/copy_nist_chars.py

And test the TextFrame to make sure everything is working right: https://github.com/maximecb/gym-miniworld/blob/master/gym_miniworld/entity.py#L244