Git development
 help / color / mirror / Atom feed
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.


  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