As of Git for Windows, v2.24.1(2). cloning a repository that contained a
file with a backslash in its name some time in the past, the command will
succeed but at the same time print errors like this:
error: filename in tree entry contains backslash: '\'
A corresponding git fetch will also show those errors, but fail.
The reason is that v2.24.1 is much more strict about backslashes in tree
entries than earlier versions. The intention was actually to prevent
checking out such files, though: if there was a mistake in a repository long
ago that has been fixed long since, there is actually no reason why we
should require the history to be rewritten.
This fixes https://github.com/git-for-windows/git/issues/2435.
The idea of this patch is to stop complaining about tree entries, and focus
instead on the index: whenever a file is added to the index, we do not want
any backslashes in the file name on Windows.
As before, this check is only performed on Windows, and only under
core.protectNTFS. On other platforms, even if core.protectNTFS is turned on,
the backslash is not a directory separator, therefore the Operating System's
syscalls will (should?) refuse to create files on NTFS with backslashes in
their file name.
I would appreciate reviews with a particular eye on keeping users safe: I am
not 100% certain that all relevant file writes go through the index (I think
that they all go through the index, but I might have well missed a corner
case).
Changes since v1:
* Clarified the commit message (what is the goal, explain that the
requirement is now loosened, explain why the code is still
GIT_WINDOWS_NATIVE-only, etc).
Johannes Schindelin (1):
mingw: only test index entries for backslashes, not tree entries
read-cache.c | 5 +++++
t/t7415-submodule-names.sh | 7 ++++---
tree-walk.c | 6 ------
3 files changed, 9 insertions(+), 9 deletions(-)
base-commit: 12029dc57db23baef008e77db1909367599210ee
Published-As: https://github.com/gitgitgadget/git/releases/tag/pr-git-682%2Fdscho%2Fmingw-only-error-on-backslash-in-index-v2
Fetch-It-Via: git fetch https://github.com/gitgitgadget/git pr-git-682/dscho/mingw-only-error-on-backslash-in-index-v2
Pull-Request: https://github.com/git/git/pull/682
Range-diff vs v1:
1: 4a120fd0b3 ! 1: d6da8315d3 mingw: only test index entries for backslashes, not tree entries
@@ -8,14 +8,31 @@
error: filename in tree entry contains backslash: '\'
- While the clone still succeeds, a similar error prevents the equivalent
- `git fetch` operation, which is inconsistent.
+ 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, anyway: As long as the
- user never checks out the files whose names contain backslashes, there
- should not be any problem in the first place.
+ 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 instead prevent such files to be added to the index.
+ 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 https://github.com/git-for-windows/git/issues/2435
--
gitgitgadget
