Note: Git 2.14 (Q3 2017) will make Git more robust when using paths with backslash.
It makes sure that "foo\bar\baz
" in "git fetch foo\bar\baz
", even though there is no slashes in it, cannot be a nickname (as in git remote
name) for a remote on Windows, as that is likely to be a pathname on a local filesystem.
See commit d9244ec (25 May 2017), and commit e20b5b5 (22 May 2017) by Johannes Sixt (j6t
).
(Merged by Junio C Hamano -- gitster
-- in commit 7d26aa3, 02 Jun 2017)
Windows: do not treat a path with backslashes as a remote's nick name
On Windows, the remote repository name in, e.g., git fetch foo\bar
is clearly not a nickname for a configured remote repository.
However, the function valid_remote_nick()
does not account for backslashes.
Use is_dir_sep()
to check for both slashes and backslashes on Windows.
This was discovered while playing with Duy's patches that warn after
fopen()
failures.
The functions that read the branches and remotes
files are protected by a valid_remote_nick()
check.
Without this change, a Windows style absolute path is incorrectly regarded as
nickname and is concatenated to a prefix and used with fopen()
.
This triggers warnings because a colon in a path name is not allowed:
C:\Temp\gittest>git fetch C:\Temp\gittest
warning: unable to access '.git/remotes/C:\Temp\gittest': Invalid argument
warning: unable to access '.git/branches/C:\Temp\gittest': Invalid argument
From C:\Temp\gittest
* branch HEAD -> FETCH_HEAD