Pycharm behaving strange with Git (Filename in tree entry contains backslash)

Question

I just got a new laptop and wanted to clone my universities git repository with pycharm.

Whenever I try to clone the repository, using either Git bash/GUI

Answer 1

See VonC's answer for update on the issue

---

There is an open issue on git-for-windows repository (for v2.24)

Git 2.24 breaks existing repositories: filename in tree entry contains backslash

The workaround as suggested by user carlescufi is to disable core.protectNTFS.

git config --global core.protectNTFS false

Quoting git docs here,

core.protectNTFS

If set to true, do not allow checkout of paths that would cause problems with the NTFS filesystem, e.g. conflict with 8.3 "short" names. Defaults to true on Windows, and false elsewhere.

Answer 2

With Git 2.25 (Q1 2020), the issue should be resolved.
An earlier update to Git for Windows declared that a tree object is invalid if it has a path component with backslash in it, which was overly strict, which has been corrected.

The only protection the Windows users need is to prevent such path (or any path that their filesystem cannot check out) from entering the index.

See commit 224c7d7 (31 Dec 2019) by Johannes Schindelin (dscho).
^{(Merged by Junio C Hamano -- gitster -- in commit a578ef9, 06 Jan 2020)}

mingw: only test index entries for backslashes, not tree entries

^{Signed-off-by: Johannes Schindelin}

During a clone of a repository that contained a file with a backslash in its name in the past, as of v2.24.1(2), Git for Windows prints errors like this:

error: filename in tree entry contains backslash: '\'

The idea is to prevent Git from even trying to write files with backslashes in their file names: while these characters are valid in file names on other platforms, on Windows it is interpreted as directory separator (which would obviously lead to ambiguities, e.g. when there is a file a\b and there is also a file a/b).

Arguably, this is the wrong layer for that error: As long as the user never checks out the files whose names contain backslashes, there should not be any problem in the first place.

So let's loosen the requirements: we now leave tree entries with backslashes in their file names alone, but we do require any entries that are added to the Git index to contain no backslashes on Windows.

Note: just as before, the check is guarded by core.protectNTFS (to allow overriding the check by toggling that config setting), and it is _only_ performed on Windows, as the backslash is not a directory separator elsewhere, even when writing to NTFS-formatted volumes.

An alternative approach would be to try to prevent creating files with backslashes in their file names. However, that comes with its own set of problems.
For example, git config -f C:\ProgramData\Git\config ... is a very valid way to specify a custom config location, and we obviously do _not_ want to prevent that.
Therefore, the approach chosen in this patch would appear to be better.

This addresses git-for-windows/git issue 2435

(issue mentioned in Saurabh P Bhandari's answer)

Answer 3

I've fixed the problem (for now), by downgrading to Git for Windows 2.23.0. The problem persists on the newest version and is reproducable on my desktop.