0

Hi Community and Git pros,

I just updated to GitExtensions-3.5.4.12724-65f01f399 and Git-2.35.1.2-64-bit from some quite old versions.

When I open the 'Commit window' in GitExtensions I see the image linked here

It seems there are some encoding issues and got the error message when I tried to reset the files. I'm confused what is present now in the cache, working dir, index, tree and so on.

The two files are present in the file system with 'ü' but marked as 'removed' in the commit index. My aim is mainly to get this two wrongly formatted files out of the index to proceed.

git reset doesn't change anything.

git clean (-f) doesn't change the situation, too.

git read-tree did something but then I saw all files from the current merge commit once in the unstaged window and once in the staged window.

If somebody has a clue I would appreciate a lot!

ndvr
  • 1
  • File names with umlauts and some other accents are problematic on some Windows and macOS file systems. They work well on Linux. In general the *easiest* thing is to stop using such names—rename a file from `schön` to `schoen` for instance. Do this on the Linux system, where the names all work. – torek Feb 24 '22 at 11:17
  • Hello torek, thanks for the advice. I'm caring about that matter already but here I'm working on an already existing repository / project where I was confronted with that issue after updating Git. I could try to rename the two files but I assume that the cache, the index and/or the file system will keep misunderstanding each other. As described, the files are in the filesystem but marked as deleted in Git, reverting that action leads Git to saying something like: I don't know these files. – ndvr Feb 25 '22 at 12:54
  • What's happening here is that *Git* can store any arbitrary byte pattern (well, almost any) for a file name: e.g., both and are valid names inside a Git commit. But the OS you're using disagrees, so when Git tries to create a new file using one of those names, the OS creates or re-uses a file with the *other* name instead. Later, Git looks at the working tree (where your active files are) and finds the "wrong" name: obviously you deleted the "right" name and created this "wrong" name instead as a new file. – torek Feb 25 '22 at 19:49
  • Of course, *you* did not do that. Your *OS* did that *to* Git. Git understands case-folding file systems, where the OS says that the file name `readme.txt` names the *same* file as the file name `README.TXT` or `readme.TXT`; you can tell Git that your OS does this kind of thing to you (and in fact Git figures that out on its own in advance). But Git doesn't understand the more complex Unicode world. – torek Feb 25 '22 at 19:50

1 Answers1

0

I had the exact same problem after converting Mercurial repos (which contained filenames with German umlauts) to Git.

I found the solution in this answer (written by someone else who also had this problem).

Here's the relevant part:

Running

git status

on my working copy showed all files with non-ASCII characters in their names as untracked files. So I continued researching and followed this advice:

git rm -rf --cached \*  
git add --all
git commit

That worked for me as well. For each repo that had files with mangled umlauts, I renamed them once, executed git rm... as shown above, and committed the changes.

Christian Specht
  • 35,843
  • 15
  • 128
  • 182