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
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 filea/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)