summaryrefslogtreecommitdiff
path: root/t/t5580-clone-push-unc.sh
AgeCommit message (Collapse)AuthorFilesLines
2019-01-18mingw: special-case arguments to `sh`Libravatar Johannes Schindelin1-1/+1
The MSYS2 runtime does its best to emulate the command-line wildcard expansion and de-quoting which would be performed by the calling Unix shell on Unix systems. Those Unix shell quoting rules differ from the quoting rules applying to Windows' cmd and Powershell, making it a little awkward to quote command-line parameters properly when spawning other processes. In particular, git.exe passes arguments to subprocesses that are *not* intended to be interpreted as wildcards, and if they contain backslashes, those are not to be interpreted as escape characters, e.g. when passing Windows paths. Note: this is only a problem when calling MSYS2 executables, not when calling MINGW executables such as git.exe. However, we do call MSYS2 executables frequently, most notably when setting the use_shell flag in the child_process structure. There is no elegant way to determine whether the .exe file to be executed is an MSYS2 program or a MINGW one. But since the use case of passing a command line through the shell is so prevalent, we need to work around this issue at least when executing sh.exe. Let's introduce an ugly, hard-coded test whether argv[0] is "sh", and whether it refers to the MSYS2 Bash, to determine whether we need to quote the arguments differently than usual. That still does not fix the issue completely, but at least it is something. Incidentally, this also fixes the problem where `git clone \\server\repo` failed due to incorrect handling of the backslashes when handing the path to the git-upload-pack process. Further, we need to take care to quote not only whitespace and backslashes, but also curly brackets. As aliases frequently go through the MSYS2 Bash, and as aliases frequently get parameters such as HEAD@{yesterday}, this is really important. As an early version of this patch broke this, let's make sure that this does not regress by adding a test case for that. Helped-by: Kim Gybels <kgybels@infogroep.be> Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-01-18mingw (t5580): document bug when cloning from backslashed UNC pathsLibravatar Johannes Schindelin1-0/+5
Due to a quirk in Git's method to spawn git-upload-pack, there is a problem when passing paths with backslashes in them: Git will force the command-line through the shell, which has different quoting semantics in Git for Windows (being an MSYS2 program) than regular Win32 executables such as git.exe itself. The symptom is that the first of the two backslashes in UNC paths of the form \\myserver\folder\repository.git is *stripped off*. Document this bug by introducing a test case. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-11-01t5580: add Cygwin supportLibravatar Adam Dinwoodie1-4/+10
t5580 tests that specifying Windows UNC paths works with Git. Cygwin supports UNC paths, albeit only using forward slashes, not backslashes, so run the compatible tests on Cygwin as well as MinGW. The only complication is Cygwin's `pwd`, which returns a *nix-style path, and that's not suitable for calculating the UNC path to the current directory. Instead use Cygwin's `cygpath` utility to get the Windows-style path. Signed-off-by: Adam Dinwoodie <adam@dinwoodie.org> Reviewed-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-06-02mingw_fopen: report ENOENT for invalid file namesLibravatar Johannes Sixt1-1/+1
On Windows, certain characters are prohibited in file names, most prominently the colon. When fopen() is called with such an invalid file name, the underlying Windows API actually reports a particular error, but since there is no suitable errno value, this error is translated to EINVAL. Detect the case and report ENOENT instead. Signed-off-by: Johannes Sixt <j6t@kdbg.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-06-02mingw: verify that paths are not mistaken for remote nicknamesLibravatar Johannes Schindelin1-2/+8
This added test case simply verifies that users will not be bothered with bogus complaints à la warning: unable to access '.git/remotes/D:\repo': Invalid argument when fetching from a Windows path (in this case, D:\repo). [j6t: mark the new test as test_expect_failure] Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Johannes Sixt <j6t@kdbg.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-01-07mingw: add a regression test for pushing to UNC pathsLibravatar Johannes Schindelin1-0/+48
On Windows, there are "UNC paths" to access network (AKA shared) folders, of the form \\server\sharename\directory. This provides a convenient way for Windows developers to share their Git repositories without having to have a dedicated server. Git for Windows v2.11.0 introduced a regression where pushing to said UNC paths no longer works, although fetching and cloning still does, as reported here: https://github.com/git-for-windows/git/issues/979 This regression was fixed in 7814fbe3f1 (normalize_path_copy(): fix pushing to //server/share/dir on Windows, 2016-12-14). Let's make sure that it does not regress again, by introducing a test that uses so-called "administrative shares": disk volumes are automatically shared under certain circumstances, e.g. the C: drive is shared as \\localhost\c$. The test needs to be skipped if the current directory is inaccessible via said administrative share, of course. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>