From: "Torsten Bögershausen" <tboegi@web.de>
To: Ramsay Jones <ramsay@ramsayjones.plus.com>
Cc: GIT Mailing-list <git@vger.kernel.org>,
Johannes Schindelin <Johannes.Schindelin@gmx.de>,
Patrick Steinhardt <ps@pks.im>,
Junio C Hamano <gitster@pobox.com>, Johannes Sixt <j6t@kdbg.org>,
Adam Dinwoodie <git@dinwoodie.org>
Subject: Re: cygwin v2.55.0 test failures
Date: Sun, 12 Jul 2026 22:04:27 +0200 [thread overview]
Message-ID: <20260712200426.GA11328@tb-raspi4> (raw)
In-Reply-To: <f65466c9-bede-472e-ad57-e72a5289be27@ramsayjones.plus.com>
On Fri, Jul 10, 2026 at 07:32:23PM +0100, Ramsay Jones wrote:
[snip]
Hej Ramsay,
Thanks for picking this up - I have some smaller comments inline,
trying to be helpful.
> As luck would have it, I left a note to myself about the remaining two
> failure cases. This leads to the remaining hunk, to connect.c, in the patch
> below; ie. the removal of a conditional (which should only fire for GfW and
> cygwin). The '#ifdef DUMMY/#endif' should probably be replaced with an
> '#ifdef GIT_WINDOWS_NATIVE/#endif' so that GfW is not affected. (Having said
> that, I suspect that even GfW should drop it ['somebody was smoking something
> exotic'], but I have no way to test it, so ...).
> Personally, I would be quite happy to rip out all win32 path handling and
> only support POSIX paths (I have been using cygwin since about 1996 and
> have only ever used win32 paths when testing git ... that is the whole
> point of cygwin! :) ), but I already know that that is a no-go. (there is
> always somebody that complains when you suggest it).
As cygwin supports/allows win32 paths: we do support them in Git as well.
(and nobody is forced to use them)
>
> So, for now anyway, it seems that I need to tidy up the patch and move in
> the opposite direction to e.g. commit 1cadad6f65 ("git clone <url>
> C:\cygwin\home\USER\repo' is working (again)", 2018-12-15).
>
> Part of the reason for vacillating on the correct way forward with this
> patch, was because I have often thought that I should use the cygwin API
> to cater to both POSIX and win32 paths. For example, we could possibly use
> the 'cygwin_conv_path()' function to do the path conversion (somewhat
> similar to the macos pre-composed-utf8 stuff, minus the directory reading).
> However, I think that would open a different can of worms, including some
> potential memory leaks. So, not exactly a slam dunk.
>
> [I also had a note-to-self about 'mixed / and \ urls' in the config file
> which is exposed by these same tests. So, another patch may be needed?]
Not sure if I follow. cygwin allows mixed / and \ . What should be patched ?
>
> Anyway, something to think about. Hmm, I suspect it would be best to just
> tidy up this patch first. ;)
>
> Just FYI. Thanks!
>
> ATB,
> Ramsay Jones
> diff --git a/connect.c b/connect.c
> index 47e39d2a73..6f5715e938 100644
> --- a/connect.c
> +++ b/connect.c
> @@ -1088,10 +1088,12 @@ static enum url_scheme parse_connect_url(const char *url_orig, char **ret_host,
>
> if (scheme == URL_SCHEME_LOCAL)
> path = end;
> +#ifdef DUMMY
> else if (scheme == URL_SCHEME_FILE && *host != '/' &&
> !has_dos_drive_prefix(host) &&
> offset_1st_component(host - 2) > 1)
> path = host - 2; /* include the leading "//" */
> +#endif
This very lines come from
commit ebb8d2c90fb0840a0803935804e37e2205505f23
mingw: support UNC in git clone file://server/share/repo
...and I can not see a reason to remove it.
next prev parent reply other threads:[~2026-07-12 20:04 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-07-10 18:32 cygwin v2.55.0 test failures Ramsay Jones
2026-07-12 20:04 ` Torsten Bögershausen [this message]
2026-07-13 20:15 ` Ramsay Jones
2026-07-13 11:06 ` Patrick Steinhardt
2026-07-13 20:28 ` Ramsay Jones
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=20260712200426.GA11328@tb-raspi4 \
--to=tboegi@web.de \
--cc=Johannes.Schindelin@gmx.de \
--cc=git@dinwoodie.org \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--cc=j6t@kdbg.org \
--cc=ps@pks.im \
--cc=ramsay@ramsayjones.plus.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox