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 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.