All of lore.kernel.org
 help / color / mirror / Atom feed
From: Johannes Sixt <j6t@kdbg.org>
To: Johannes Schindelin <Johannes.Schindelin@gmx.de>
Cc: Git Mailing List <git@vger.kernel.org>, gitster@pobox.com
Subject: Re: [PATCH 0/2] Fix warnings on access of a remote with Windows paths
Date: Tue, 23 May 2017 20:39:06 +0200	[thread overview]
Message-ID: <574f9050-e711-e83c-ba93-6be2dc2a44bc@kdbg.org> (raw)
In-Reply-To: <alpine.DEB.2.21.1.1705231248150.3610@virtualbox>

Am 23.05.2017 um 12:53 schrieb Johannes Schindelin:
> Hi Hannes (& Junio, see below),
> 
> On Mon, 22 May 2017, Johannes Sixt wrote:
> 
>> Am 22.05.2017 um 13:59 schrieb Johannes Schindelin:
>>> On Sat, 20 May 2017, Johannes Sixt wrote:
>>>> This small series fixes these warnings on Windows:
>>>>
>>>> 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
>>>> warning: argument
>>>>   From C:\Temp\gittest
>>>>    * branch            HEAD       -> FETCH_HEAD
>>>>
>>>> The fix is in the second patch; the first patch is a
>>>> preparation that allows to write the fix in my preferred style.
>>>
>>> Thank you!
>>>
>>> Maybe you want to accompany these patches with a simple test case that
>>> uses e.g. ls-remote on $(pwd | tr / \\\\)?
>>
>> Actually, no, I don't want to. It would have to be protected by MINGW, and I
>> don't want to burden us (and here I mean Windows folks) with a check for a
>> cosmetic deficiency. (Shell scripts, slow forks, yadda, yadda...)
> 
> Actually, yes, I want to.
> 
> Yes, it would have to be protected by MINGW, and yes, it would put a
> burden on us, but also yes: it would put an even higher burden on me to
> check this manually before releasing Git for Windows, or even worse: this
> regression would be the kind of bug that triggers many bug reports,
> addressing which would take a lot more time than writing this test case
> and executing it as part of our test suite.

Fair enough. The patch looks good. I'll be able to test no earlier than 
Monday, though.

> 
> So here goes:
> 
> -- snipsnap --
> From: Johannes Schindelin <johannes.schindelin@gmx.de>
> Date: Tue, 23 May 2017 12:42:13 +0200
> Subject: [PATCH] mingw: verify that paths are not mistaken for remote nicknames
> 
> 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).
> 
> Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
> ---
>   t/t5580-clone-push-unc.sh | 10 ++++++++--
>   1 file changed, 8 insertions(+), 2 deletions(-)
> 
> diff --git a/t/t5580-clone-push-unc.sh b/t/t5580-clone-push-unc.sh
> index b195f71ea98..93ce99ba3c6 100755
> --- a/t/t5580-clone-push-unc.sh
> +++ b/t/t5580-clone-push-unc.sh
> @@ -1,13 +1,19 @@
>   #!/bin/sh
>   
> -test_description='various UNC path tests (Windows-only)'
> +test_description='various Windows-only path tests'
>   . ./test-lib.sh
>   
>   if ! test_have_prereq MINGW; then
> -	skip_all='skipping UNC path tests, requires Windows'
> +	skip_all='skipping Windows-only path tests'
>   	test_done
>   fi
>   
> +test_expect_success 'remote nick cannot contain backslashes' '
> +	BACKSLASHED="$(pwd | tr / \\\\)" &&
> +	git ls-remote "$BACKSLASHED" >out 2>err &&
> +	! grep "unable to access" err
> +'
> +
>   UNCPATH="$(pwd)"
>   case "$UNCPATH" in
>   [A-Z]:*)
> 


  reply	other threads:[~2017-05-23 18:39 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-05-20  6:28 [PATCH 0/2] Fix warnings on access of a remote with Windows paths Johannes Sixt
2017-05-20  6:28 ` [PATCH 1/2] mingw.h: permit arguments with side effects for is_dir_sep Johannes Sixt
2017-05-22 11:52   ` Johannes Schindelin
2017-05-20  6:28 ` [PATCH 2/2] Windows: do not treat a path with backslashes as a remote's nick name Johannes Sixt
2017-05-22 11:56   ` Johannes Schindelin
2017-05-22 11:59 ` [PATCH 0/2] Fix warnings on access of a remote with Windows paths Johannes Schindelin
2017-05-22 16:36   ` Johannes Sixt
2017-05-23 10:53     ` Johannes Schindelin
2017-05-23 18:39       ` Johannes Sixt [this message]
2017-05-22 12:38 ` stefan.naewe
2017-05-22 14:01   ` Johannes Schindelin
2017-05-22 16:28     ` Johannes Sixt
2017-05-23 10:46       ` Johannes Schindelin
2017-05-23 22:08         ` Junio C Hamano
2017-05-24  5:45           ` Johannes Sixt
2017-05-25 12:00             ` [PATCH v3 2/2] Windows: do not treat a path with backslashes as a remote's nick name Johannes Sixt
2017-05-25 23:16               ` Junio C Hamano
2017-05-22 18:58 ` [PATCH v2 1/2] mingw.h: permit arguments with side effects for is_dir_sep Johannes Sixt
2017-05-22 19:01   ` [PATCH v2 2/2] Windows: do not treat a path with backslashes as a remote's nick name Johannes Sixt

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=574f9050-e711-e83c-ba93-6be2dc2a44bc@kdbg.org \
    --to=j6t@kdbg.org \
    --cc=Johannes.Schindelin@gmx.de \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.