Git problem on Macos

Development
1

I have haiku cloned on macos (15.2) (with a case in-sensitive fs) but there is trash in my working tree that II don’t know how to get rid of.

% git -v
git version 2.39.3 (Apple Git-146)
% git branch -v
* master 4c73b06622 hid: Fix for incoming feature reports not parsed
 % git status
On branch master
Your branch is up to date with 'origin/master'.

Changes not staged for commit:
  (use "git add <file>..." to update what will be committed)
  (use "git restore <file>..." to discard changes in working directory)
	modified:   data/catalogs/apps/screenshot/screenshot/be.catkeys
	modified:   data/catalogs/apps/screenshot/screenshot/ca.catkeys
	modified:   data/catalogs/apps/screenshot/screenshot/cs.catkeys
	modified:   data/catalogs/apps/screenshot/screenshot/da.catkeys
	modified:   data/catalogs/apps/screenshot/screenshot/de.catkeys
	modified:   data/catalogs/apps/screenshot/screenshot/el.catkeys
	modified:   data/catalogs/apps/screenshot/screenshot/eo.catkeys
	modified:   data/catalogs/apps/screenshot/screenshot/es.catkeys
	modified:   data/catalogs/apps/screenshot/screenshot/fi.catkeys
	modified:   data/catalogs/apps/screenshot/screenshot/fr.catkeys
	modified:   data/catalogs/apps/screenshot/screenshot/fur.catkeys
	modified:   data/catalogs/apps/screenshot/screenshot/hr.catkeys
	modified:   data/catalogs/apps/screenshot/screenshot/hu.catkeys
	modified:   data/catalogs/apps/screenshot/screenshot/id.catkeys
	modified:   data/catalogs/apps/screenshot/screenshot/it.catkeys
	modified:   data/catalogs/apps/screenshot/screenshot/ja.catkeys
	modified:   data/catalogs/apps/screenshot/screenshot/ko.catkeys
	modified:   data/catalogs/apps/screenshot/screenshot/lt.catkeys
	modified:   data/catalogs/apps/screenshot/screenshot/nb.catkeys
	modified:   data/catalogs/apps/screenshot/screenshot/nl.catkeys
	modified:   data/catalogs/apps/screenshot/screenshot/pl.catkeys
	modified:   data/catalogs/apps/screenshot/screenshot/pt.catkeys
	modified:   data/catalogs/apps/screenshot/screenshot/pt_BR.catkeys
	modified:   data/catalogs/apps/screenshot/screenshot/ro.catkeys
	modified:   data/catalogs/apps/screenshot/screenshot/ru.catkeys
	modified:   data/catalogs/apps/screenshot/screenshot/sk.catkeys
	modified:   data/catalogs/apps/screenshot/screenshot/sv.catkeys
	modified:   data/catalogs/apps/screenshot/screenshot/th.catkeys
	modified:   data/catalogs/apps/screenshot/screenshot/tr.catkeys
	modified:   data/catalogs/apps/screenshot/screenshot/uk.catkeys
	modified:   data/catalogs/apps/screenshot/screenshot/zh_Hans.catkeys
	modified:   src/tests/kits/locale/CollatorTest.cpp

no changes added to commit (use "git add" and/or "git commit -a")

I have tried:
git reset --hard HEAD

deleting the files and then using git restore

using git restore /*

using git restore

What am I missing? Do I have to delete the repo and start over? I’ve not done anything with that clone yet (apart from a git pull to update it today) so this issue baffles me.

The updated catkeys files there are indeed updated catkey files.

2

What do git config --get core.autocrlf and git config --global --get core.autocrlf return?

3

That returns nothing (exit code 1)
Why would that matter? Macos and Haiku both use the same line endings iiirc?
(and the git diff has differences that are not line endings)

4

My guess was that was your issue. Have you tried git restore . with dot?

5

You mean dot as in current dir? assuming you mean to do that in the root of the checkout, no I hadn’t.

I tried that now, but the output from status is still the same.

1 Like
6

Run git checkout-index -fa. If no difference then git checkout . from the root of working tree. If that doesn’t do it then I’m out of ideas :smile:

7

No change.
I guess I will have to follow the xkcd advice then

3 Likes
8

I guess I will have to follow the xkcd advice then

That won’t do.

with a case in-sensitive fs

Unfortunately, we currently have data/catalogs/apps/screenshot/screenshot and data/catalogs/apps/screenshot/Screenshot. There’s been some talk of unifying /bin/screenshot and /system/apps/Screenshot, which I guess are the origin of those two sets.

9

I’m confused, I formatted it when installing so the case is not specially treated. Why should that be the problem then?

10

I may be wrong here, as the filesystems I use are case-sensitive, but for each of the files in that list there’s another one in the repo with a full path diferring only in case. So, when asked to look for changes, git checks them and finds the same file in the filesystem. For one it will see no change, for the other the whole content is different.

11

I’m guessing I got confused by english here. I explicitly formated it as case insensitive because I don’t want special support for Casing of file names.

Why does case insenitive mean “does not support diifferenciating filenames based on case” and not that it does support this? (I.e insenstivie as in not sensitive to this…)

Couldn’t there be a better name? filesystem mangles names? Darn.

It’s a more complex code-path to explicitly do this based on locale and what languages think is or isn’t uppercase. ugh.

EDIT: I am mostly annoyed that I knew about this problem beforehand and tried to explicitly format the filesystem so this wouldn’t become a problem, and got tricked by the wording : /

12

It’s the other way. Case sensitive means it’s sensitive to casing, “FILE” and “file” are different. Case insensitive is when it doesn’t mind the case you are using, you get the same file.

13

That is confusing wording to me.

Case sensitive implies it places special value on casing, which a filesystem that ignores upper/lower case as a concept does not do.

A system that is not senitive to cases would be the one that would allow severall files with different casing because it cannot tell that (in a humans mind) some letters may be the same.

That is a bit like saying the current filesystem is “math symbols sensitive” because it makes a difference between normal latin letters and the ones in the unicode math block, instead of conflating them

Anyway, I guess I will reformat the system. Or make a new APFS container and mount it somewhere special.

14

Well, that’s not what it means.

Case sensitive means the filesystem notices differences in case.

Case insensitive means the filesystem does not notice differences in case.

Maybe think of it in the same way as “color blind”. A person who is color blind is not sensitive to colors. If you normally see colors and you want to be color blind for some reason, you have to wear special glasses with color filters. Or if we are talking about software, making an image processing “color insensitive” probably means something like converting the picture to greyscale in some way. So, yes, in that case, being color blind is more complicated than being color-seeing.

And so is it for “case insensitive”. “insensitive” is just a more general form of “blind”, that does not apply only to the sense of sight. A case insensitive filesystem is one that has been made to not be able to sense case.

3 Likes
15

In your analogy the case insentive filesystem can see the difference between “file” and “FIle”, while the case sensitive filesystem cannot.
Wouldn’t the case sensitive one be the color blind person?

edit: ah. other way around. I think I understand what you ment now.

I will remember to look it up next time this comes up for me, I doubt that an explanation helps me at this point, It will stick in my mind as that one thing that was backwards/the other way around, so will probably pick the wrong thing again if I don’t double check.

I appreciate the explanation however. Thanks : )

16

I use Git on my MorphOS box but case sensitivity isn’t available on Amiga-like operating systems. I often have to go into GitHub with the browser or download the repo on my Linux box to straighten out case sensitive problems.