diff mbox series

[v2,1/3] git clone <url> C:\cygwin\home\USER\repo' is working (again)

Message ID 20181207170456.8994-1-tboegi@web.de (mailing list archive)
State New, archived
Headers show
Series [v2,1/3] git clone <url> C:\cygwin\home\USER\repo' is working (again) | expand

Commit Message

Torsten Bögershausen Dec. 7, 2018, 5:04 p.m. UTC
From: Torsten Bögershausen <tboegi@web.de>

A regression for cygwin users was introduced with commit 05b458c,
 "real_path: resolve symlinks by hand".

In the the commit message we read:
  The current implementation of real_path uses chdir() in order to resolve
    symlinks.  Unfortunately this isn't thread-safe as chdir() affects a
      process as a whole...

The old (and non-thread-save) OS calls chdir()/pwd() had been
replaced by a string operation.
The cygwin layer "knows" that "C:\cygwin" is an absolute path,
but the new string operation does not.

"git clone <url> C:\cygwin\home\USER\repo" fails like this:
fatal: Invalid path '/home/USER/repo/C:\cygwin\home\USER\repo'

The solution is to implement has_dos_drive_prefix(), skip_dos_drive_prefix()
is_dir_sep(), offset_1st_component() and convert_slashes() for cygwin
in the same way as it is done in 'Git for Windows' in compat/mingw.[ch]

Instead of duplicating the code, it is extracted into compat/mingw-cygwin.[ch]
Some need for refactoring and cleanup came up in the review, they are adressed
in a seperate commit.

Reported-By: Steven Penny <svnpenn@gmail.com>
Signed-off-by: Torsten Bögershausen <tboegi@web.de>
---
 compat/cygwin.c       | 19 -------------------
 compat/cygwin.h       |  2 --
 compat/mingw-cygwin.c | 28 ++++++++++++++++++++++++++++
 compat/mingw-cygwin.h | 20 ++++++++++++++++++++
 compat/mingw.c        | 29 +----------------------------
 compat/mingw.h        | 20 --------------------
 config.mak.uname      |  4 ++--
 git-compat-util.h     |  3 ++-
 8 files changed, 53 insertions(+), 72 deletions(-)
 delete mode 100644 compat/cygwin.c
 delete mode 100644 compat/cygwin.h
 create mode 100644 compat/mingw-cygwin.c
 create mode 100644 compat/mingw-cygwin.h

Comments

Johannes Schindelin Dec. 7, 2018, 9:53 p.m. UTC | #1
Hi Torsten,

On Fri, 7 Dec 2018, tboegi@web.de wrote:

>  compat/mingw-cygwin.c | 28 ++++++++++++++++++++++++++++
>  compat/mingw-cygwin.h | 20 ++++++++++++++++++++

Please use compat/win32/path.c (or .../path-utils.c) instead. This is not
so much about MINGW or Cygwin or MSys or MSYS2 or Visual C++, but about
Windows.

Thanks,
Johannes
Steven Penny Dec. 8, 2018, 12:49 a.m. UTC | #2
On Fri, Dec 7, 2018 at 11:04 AM wrote:
> The solution is to implement has_dos_drive_prefix(), skip_dos_drive_prefix()
> is_dir_sep(), offset_1st_component() and convert_slashes() for cygwin
> in the same way as it is done in 'Git for Windows' in compat/mingw.[ch]
>
> Instead of duplicating the code, it is extracted into compat/mingw-cygwin.[ch]
> Some need for refactoring and cleanup came up in the review, they are adressed
> in a seperate commit.

i have applied the 3 patches against current master, and my original test
passes, so looks good to me.

however like Johannes i take issue with the naming. as he said "mingw-cygwin"
really isnt appropriate. ideally it would be "windows.h", but as that is
conspicuously in use, something like these:

- pc-windows
- pc-win
- win

i disagree with him on using "win32" - that doesnt really make sense, as
obviously you can compile 64-bit Git for Windows. if you wanted to go that route
you would want to use something like:

- windows-api
- win-api
- winapi

further - i disagree with the "DOS" moniker being used at all. DOS is a defunkt
operating system that i dont think Git has *ever* supported, so it doesnt make
sense to be referring to it this way. again, a more approriate name would be
something like "win_drive_prefix".
Johannes Schindelin Dec. 10, 2018, 8:46 a.m. UTC | #3
Hi Steven,

please stop dropping me from the Cc: list. Thanks.

On Fri, 7 Dec 2018, Steven Penny wrote:

> On Fri, Dec 7, 2018 at 11:04 AM wrote:
>
> > The solution is to implement has_dos_drive_prefix(),
> > skip_dos_drive_prefix() is_dir_sep(), offset_1st_component() and
> > convert_slashes() for cygwin in the same way as it is done in 'Git for
> > Windows' in compat/mingw.[ch]
> >
> > Instead of duplicating the code, it is extracted into
> > compat/mingw-cygwin.[ch] Some need for refactoring and cleanup came up
> > in the review, they are adressed in a seperate commit.
> 
> i have applied the 3 patches against current master, and my original
> test passes, so looks good to me.
> 
> however like Johannes i take issue with the naming. as he said "mingw-cygwin"
> really isnt appropriate. ideally it would be "windows.h", but as that is
> conspicuously in use, something like these:
> 
> - pc-windows
> - pc-win
> - win

I find all of those horrible.

> i disagree with him on using "win32" - that doesnt really make sense,

... except if you take into account that this has been our convention for,
what, almost 9 years (since 44626dc7d5 (MSVC: Windows-native
implementation for subset of Pthreads API, 2010-01-15), to be precise)? In
that case, it makes a ton of sense, and one might be tempted to ask who
the person wanting to change that thinks they are...

> as obviously you can compile 64-bit Git for Windows. if you wanted to go
> that route you would want to use something like:
> 
> - windows-api
> - win-api
> - winapi
> 
> further - i disagree with the "DOS" moniker being used at all. DOS is a
> defunkt operating system that i dont think Git has *ever* supported, so
> it doesnt make sense to be referring to it this way. again, a more
> approriate name would be something like "win_drive_prefix".

You may disagree all you want, but given that Torsten has been a lot more
active on this code than you have been so far, I'll go with Torsten's
taste. Which incidentally happens to match my tastes, so that's an added
bonus.

Ciao,
Johannes
Steven Penny Dec. 10, 2018, 12:45 p.m. UTC | #4
On Mon, Dec 10, 2018 at 2:46 AM Johannes Schindelin wrote:
> please stop dropping me from the Cc: list. Thanks.

i dropped you specifically because i knew you were going to flame like you just
did below. oh well, i guess you cant avoid the inevitable.

> > - pc-windows
> > - pc-win
> > - win
>
> I find all of those horrible.

they arent great, but "win32" simply isnt valid. as soon as we started compiling
for 64-bit and using 64-bit APIs it didnt make sense to keep using it. if you
want to refer to all versions of the Microsoft OS you say "Windows", not
"Windows XP", as that would be confusing for people using Windows 10. In the
same vein you shouldnt refer to the current Windows API as "Win32" because its
no longer just 32-bit.

> ... except if you take into account that this has been our convention for,
> what, almost 9 years (since 44626dc7d5 (MSVC: Windows-native
> implementation for subset of Pthreads API, 2010-01-15), to be precise)? In
> that case, it makes a ton of sense, and one might be tempted to ask who
> the person wanting to change that thinks they are...

"That's the way it's always been done" is not a good reason to keep doing
something. I would say the justification goes the other way, as to why we should
keep using an old moniker when its past making sense.

> You may disagree all you want, but given that Torsten has been a lot more
> active on this code than you have been so far, I'll go with Torsten's
> taste. Which incidentally happens to match my tastes, so that's an added
> bonus.

in the end i dont really care what your taste is, or Torsten for that matter. I
care that the issue be fixed.
Johannes Schindelin Dec. 11, 2018, 1:39 p.m. UTC | #5
Hi Steven,

On Mon, 10 Dec 2018, Steven Penny wrote:

> On Mon, Dec 10, 2018 at 2:46 AM Johannes Schindelin wrote:
> > please stop dropping me from the Cc: list. Thanks.
> 
> i dropped you specifically because i knew you were going to flame like
> you just did below. oh well, i guess you cant avoid the inevitable.

I have no intention of flaming anybody. That is simply a
misrepresentation.

> > > - pc-windows
> > > - pc-win
> > > - win
> >
> > I find all of those horrible.
> 
> they arent great, but "win32" simply isnt valid.

It is a long established convention to talk about the Win32 API as the set
of functions developed for Windows NT and backported to Windows 95.

There is no benefit in abandoning that convention just to please you.

> > ... except if you take into account that this has been our convention
> > for, what, almost 9 years (since 44626dc7d5 (MSVC: Windows-native
> > implementation for subset of Pthreads API, 2010-01-15), to be
> > precise)? In that case, it makes a ton of sense, and one might be
> > tempted to ask who the person wanting to change that thinks they
> > are...
> 
> "That's the way it's always been done" is not a good reason to keep
> doing something. I would say the justification goes the other way, as to
> why we should keep using an old moniker when its past making sense.

If you want to change something that has been in use for a long time, you
have to have good reasons. None of your arguments convinces me so far that
you have any good reason to change these.

Let's hear some good argument in a well-prepared patch, or alternatively
let's just not discuss these hypotheticals anymore.

> > You may disagree all you want, but given that Torsten has been a lot
> > more active on this code than you have been so far, I'll go with
> > Torsten's taste. Which incidentally happens to match my tastes, so
> > that's an added bonus.
> 
> in the end i dont really care what your taste is, or Torsten for that
> matter. I care that the issue be fixed.

If anyone truly cares about an issue to be fixed, I would expect more
assisting, and less distracting, to do wonders.

Ciao,
Johannes
Steven Penny Dec. 12, 2018, 12:42 a.m. UTC | #6
On Tue, Dec 11, 2018 at 7:39 AM Johannes Schindelin wrote:
> I have no intention of flaming anybody. That is simply a
> misrepresentation.

you may see yourself "through a glass darkly", but i dont. this language is not
constructive:

> > - pc-windows
> > - pc-win
> > - win
>
> I find all of those horrible.

one windows triplet in use is "x86_64-pc-windows", used by Rust:

https://forge.rust-lang.org/other-installation-methods.html

which is how i came about my suggestions - again they arent great but they arent
misleading as "Win32" is.

> It is a long established convention to talk about the Win32 API as the set
> of functions developed for Windows NT and backported to Windows 95.
>
> There is no benefit in abandoning that convention just to please you.

Quoting from Wikipedia (emphasis mine):

> The **Windows API**, informally **WinAPI**, is Microsoft's core set of
> application programming interfaces (APIs) available in the Microsoft Windows
> operating systems. The name **Windows API** collectively refers to several
> different platform implementations that are often referred to by their own
> names (for example, **Win32** API)

and:

> Microsoft eventually changed the name of the then current **Win32** API family
> into **Windows API**, and made it into a catch-all term for both past and
> future API versions.

http://wikipedia.org/wiki/Windows_API

and quoting directly from Microsoft:

> The **Windows API** can be used in all Windows-based desktop applications, and
> the same functions are generally supported on 32-bit and 64-bit Windows.

http://docs.microsoft.com/windows/desktop/apiindex/api-index-portal

So again, "Win32" refers specifically to the old 32-bit only version of the API,
while:

- windows-api
- win-api
- winapi

refer to the current version.

> If you want to change something that has been in use for a long time, you
> have to have good reasons. None of your arguments convinces me so far that
> you have any good reason to change these.

i am certainly not interested in convincing you. i figured you wouldve gleaned
this from the fact that i removed you from the CC. Nevertheless, see above
links.

> If anyone truly cares about an issue to be fixed, I would expect more
> assisting, and less distracting, to do wonders.

hmm:

- http://public-inbox.org/git/CAAXzdLXSJU5bC_D1Q_gCWqKG7mcdcAvRkiYzano-VsrRRxazDQ@mail.gmail.com
- http://public-inbox.org/git/CAAXzdLXmJ1YKiTF17b=ZfkM3HtJCNkvVMQNU=riW8R42VLid_Q@mail.gmail.com
- http://public-inbox.org/git/CAAXzdLWByGC+B_XdDiJwounoPgMAsMq=EuOSx9bdV-f5vQUhnA@mail.gmail.com
- http://public-inbox.org/git/CAAXzdLXCEeZdkCXT+-0n=Fn7_=Nz5cm+6xr0w-cd6B1om028uA@mail.gmail.com
- http://public-inbox.org/git/CAAXzdLU3dsCabgYKnD9c7iWZcXx1cfO3tisJ7r0dNjiiTHk1mA@mail.gmail.com
- http://public-inbox.org/git/CAAXzdLWBSD5coxqbyRN_d9B1e4AA-Q6VQ7iRo8BPuhBKDicMRQ@mail.gmail.com
- http://public-inbox.org/git/CAAXzdLX4jU7+i1W1A_Q1LpPFa1D4FYVPW5rcMnqr_tDHEJn+tw@mail.gmail.com
- http://public-inbox.org/git/CAAXzdLWtDw09umyr23qZkv2jQ6_mTeFXbktgb-f6S2w6Zf1Egg@mail.gmail.com
Elijah Newren Dec. 12, 2018, 3:47 a.m. UTC | #7
On Fri, Dec 7, 2018 at 4:51 PM Steven Penny <svnpenn@gmail.com> wrote:
>
> On Fri, Dec 7, 2018 at 11:04 AM wrote:
> > The solution is to implement has_dos_drive_prefix(), skip_dos_drive_prefix()
> > is_dir_sep(), offset_1st_component() and convert_slashes() for cygwin
> > in the same way as it is done in 'Git for Windows' in compat/mingw.[ch]
> >
> > Instead of duplicating the code, it is extracted into compat/mingw-cygwin.[ch]
> > Some need for refactoring and cleanup came up in the review, they are adressed
> > in a seperate commit.
>
> i have applied the 3 patches against current master, and my original test
> passes, so looks good to me.
>
> however like Johannes i take issue with the naming. as he said "mingw-cygwin"
> really isnt appropriate. ideally it would be "windows.h", but as that is
> conspicuously in use, something like these:
>
> - pc-windows
> - pc-win
> - win
>
> i disagree with him on using "win32" - that doesnt really make sense, as
> obviously you can compile 64-bit Git for Windows. if you wanted to go that route
> you would want to use something like:
>
> - windows-api
> - win-api
> - winapi
>
> further - i disagree with the "DOS" moniker being used at all. DOS is a defunkt
> operating system that i dont think Git has *ever* supported, so it doesnt make
> sense to be referring to it this way. again, a more approriate name would be
> something like "win_drive_prefix".

You seem to want internal function and filenames to be based on the
product or marketing names of currently targetted systems.  I don't
see why this is desirable; could you explain why it is?

I admit that I seem to see things more from Dscho's angle.  However, I
know much less about Windows than either of you.  Perhaps my best
understanding of the situation might help, limited as it is:
  - Using currently targetted system names means future code churn --
we may have to rename functions and files for absolutely no useful
gain, muddying the history, making it harder for developers to
remember how to find things, etc., simply because an external party
renamed their libraries or introduced a new product.
  - For people less familiar with windows,
"windows-api/win-api/winapi" and "win_drive_prefix" may sound like
something only available in newer systems, making them wonder if the
file name or function name is referring to some new windows concept
they are unfamiliar with
  - Mentioning an anchor point where the relevant concept originally
targetted or where it came from (win32/path.c, dos_drive_prefix)
avoids or greatly reduces both problems.


I'm worried based on other emails in this thread that there is a
fundamental difference in frame of reference leading to a
misunderstanding about rationale for naming, and worse that folks
might not even realize where the misunderstanding is coming from,
attributing it to different motives rather than different frames of
reference.  If that's true, I hope this email can begin the process of
clearing up the differences of understanding.  If I'm wrong, then I
apologize for the noise; just ignore me.

Best wishes,
Elijah
Johannes Sixt Dec. 12, 2018, 7:29 a.m. UTC | #8
Am 12.12.18 um 01:42 schrieb Steven Penny:
> On Tue, Dec 11, 2018 at 7:39 AM Johannes Schindelin wrote:
>>> - pc-windows
>>> - pc-win
>>> - win
>>
>> I find all of those horrible.
> 
> one windows triplet in use is "x86_64-pc-windows", used by Rust:
> 
> https://forge.rust-lang.org/other-installation-methods.html
> 
> which is how i came about my suggestions - again they arent great but they arent
> misleading as "Win32" is.

As long as C:\Windows\System32 on my Windows computer contains only 
64-Bit binaries, I consider the characters "3" and "2" next to each 
other in this order just noise and without any form of information. The 
important part of the name is "win".

-- Hannes
Steven Penny Dec. 12, 2018, 12:40 p.m. UTC | #9
On Wed, Dec 12, 2018 at 1:29 AM Johannes Sixt wrote:
> As long as C:\Windows\System32 on my Windows computer contains only
> 64-Bit binaries, I consider the characters "3" and "2" next to each
> other in this order just noise and without any form of information. The
> important part of the name is "win".

sorry friend, but thats a logical fallacy :(

http://yourlogicalfallacyis.com/no-true-scotsman

just because the name "System32" is still in use (wrongly, I might add) doesnt
mean that "Win32" should still be in use.

Each name is a separate argument. The "Win32" name has been changed by Microsoft
and shouldnt be used by Git if possible. Its an easy change and I could send
a pull request myself. However just because Microsoft hasnt changed "Sytem32"
doesnt mean that they wont or shouldnt - as you said its just as misleading. We
should fix ambiguities where we can, not embrace them.
Johannes Schindelin Dec. 12, 2018, 1:33 p.m. UTC | #10
Hi Hannes,

On Wed, 12 Dec 2018, Johannes Sixt wrote:

> Am 12.12.18 um 01:42 schrieb Steven Penny:
> > On Tue, Dec 11, 2018 at 7:39 AM Johannes Schindelin wrote:
> > > > - pc-windows
> > > > - pc-win
> > > > - win
> > >
> > > I find all of those horrible.
> > 
> > one windows triplet in use is "x86_64-pc-windows", used by Rust:
> > 
> > https://forge.rust-lang.org/other-installation-methods.html
> > 
> > which is how i came about my suggestions - again they arent great but they
> > arent
> > misleading as "Win32" is.
> 
> As long as C:\Windows\System32 on my Windows computer contains only 64-Bit
> binaries, I consider the characters "3" and "2" next to each other in this
> order just noise and without any form of information. The important part of
> the name is "win".

FWIW I agree with you.

Thanks,
Dscho
Johannes Schindelin Dec. 12, 2018, 1:57 p.m. UTC | #11
Hi Elijah,

On Tue, 11 Dec 2018, Elijah Newren wrote:

> I'm worried based on other emails in this thread that there is a
> fundamental difference in frame of reference leading to a
> misunderstanding about rationale for naming, and worse that folks might
> not even realize where the misunderstanding is coming from, attributing
> it to different motives rather than different frames of reference.  If
> that's true, I hope this email can begin the process of clearing up the
> differences of understanding.  If I'm wrong, then I apologize for the
> noise; just ignore me.

I think you brought up quite a few good points (also in the part that I
did not quote).

The part I quoted brings up one particular aspect that I would like to
drive home a little more: the purpose of naming, and the historical
reality. ("hysterical raisins" comes to mind.)

In Git, we have an awful lot of references to MINGW, which is the name of
a project that tried to allow compiling software targeting pure Windows
(i.e. the Win32 API, without any POSIX compatibility layer) with the GNU C
compiler.

As many open source projects require more than just the GNU C compiler
(e.g. a Bash to run ./configure), there is also MSys, which is a minimal
fork of a then-current version of Cygwin, originally intended for the sole
purpose to support building MINGW software.

To make things more confusing, at some stage the mingw-w64 project was
started (not as a fork of MINGW, AFAIU), to address the notable lack of
64-bit support in MINGW, and later the MSYS2 project was started, based on
mingw-w64, to address the same issue with MSys (also not forking, but
instead starting from scratch).

Back in 2006, when I started to port Git to Windows, I made use of MINGW
and MSys (and I abused MSys by shipping their Bash with Git, which was
distinctly not intended a usage of their Bash). Hannes Sixt picked up when
I stopped having access to a fast Windows machine, and kept my naming:
compat/mingw.c.

Now, Philip Oakley, Jeff Hostetler and a few other developers spent quite
a bit of effort to make Git compile also with Visual C, and of course the
reused parts of compat/mingw.c (whose name now does not make too much
sense anymore, except in historical context).

Likewise, when I switched to MSYS2/mingw-w64 with the major version jump
to Git for Windows 2.x in 2015, I no longer use MINGW to compile
*anything*.

I hope that this illustrated a little bit how our names came about.

Of course, we could now spend some time to change the names to reflect
more the product and brand names involved. There does not seem to be any
really compelling reason to do so, though. And I'd rather spend my time
developing exciting features. But that's my preference for my time, so if
anybody comes along, making a strong case for renaming, in a well-crafted
patch series, who am I to say no to that.

Ciao,
Dscho
Junio C Hamano Dec. 13, 2018, 3:52 a.m. UTC | #12
Steven Penny <svnpenn@gmail.com> writes:

> On Wed, Dec 12, 2018 at 1:29 AM Johannes Sixt wrote:
>> As long as C:\Windows\System32 on my Windows computer contains only
>> 64-Bit binaries, I consider the characters "3" and "2" next to each
>> other in this order just noise and without any form of information. The
>> important part of the name is "win".
>
> sorry friend, but thats a logical fallacy :(
>
> http://yourlogicalfallacyis.com/no-true-scotsman
>
> just because the name "System32" is still in use (wrongly, I might add) doesnt
> mean that "Win32" should still be in use.
>
> Each name is a separate argument. The "Win32" name has been changed by Microsoft
> and shouldnt be used by Git if possible. Its an easy change and I could send
> a pull request myself. However just because Microsoft hasnt changed "Sytem32"
> doesnt mean that they wont or shouldnt - as you said its just as misleading. We
> should fix ambiguities where we can, not embrace them.

FWIW, in the context of the Git development ecosystem, whatever
Dscho wants to do in compat/ that is limited to Windows is
"officially endorsed by Microsoft" enough.

Also I do not think J6t felt 32 in System32 or in win32 was
misleading.  At least I didn't read the above that way.
diff mbox series

Patch

diff --git a/compat/cygwin.c b/compat/cygwin.c
deleted file mode 100644
index b9862d606d..0000000000
--- a/compat/cygwin.c
+++ /dev/null
@@ -1,19 +0,0 @@ 
-#include "../git-compat-util.h"
-#include "../cache.h"
-
-int cygwin_offset_1st_component(const char *path)
-{
-	const char *pos = path;
-	/* unc paths */
-	if (is_dir_sep(pos[0]) && is_dir_sep(pos[1])) {
-		/* skip server name */
-		pos = strchr(pos + 2, '/');
-		if (!pos)
-			return 0; /* Error: malformed unc path */
-
-		do {
-			pos++;
-		} while (*pos && pos[0] != '/');
-	}
-	return pos + is_dir_sep(*pos) - path;
-}
diff --git a/compat/cygwin.h b/compat/cygwin.h
deleted file mode 100644
index 8e52de4644..0000000000
--- a/compat/cygwin.h
+++ /dev/null
@@ -1,2 +0,0 @@ 
-int cygwin_offset_1st_component(const char *path);
-#define offset_1st_component cygwin_offset_1st_component
diff --git a/compat/mingw-cygwin.c b/compat/mingw-cygwin.c
new file mode 100644
index 0000000000..c63d7acb9c
--- /dev/null
+++ b/compat/mingw-cygwin.c
@@ -0,0 +1,28 @@ 
+#include "../git-compat-util.h"
+
+int mingw_cygwin_skip_dos_drive_prefix(char **path)
+{
+	int ret = has_dos_drive_prefix(*path);
+	*path += ret;
+	return ret;
+}
+
+int mingw_cygwin_offset_1st_component(const char *path)
+{
+	char *pos = (char *)path;
+
+	/* unc paths */
+	if (!skip_dos_drive_prefix(&pos) &&
+			is_dir_sep(pos[0]) && is_dir_sep(pos[1])) {
+		/* skip server name */
+		pos = strpbrk(pos + 2, "\\/");
+		if (!pos)
+			return 0; /* Error: malformed unc path */
+
+		do {
+			pos++;
+		} while (*pos && !is_dir_sep(*pos));
+	}
+
+	return pos + is_dir_sep(*pos) - path;
+}
diff --git a/compat/mingw-cygwin.h b/compat/mingw-cygwin.h
new file mode 100644
index 0000000000..66ccc909ae
--- /dev/null
+++ b/compat/mingw-cygwin.h
@@ -0,0 +1,20 @@ 
+#define has_dos_drive_prefix(path) \
+	(isalpha(*(path)) && (path)[1] == ':' ? 2 : 0)
+int mingw_cygwin_skip_dos_drive_prefix(char **path);
+#define skip_dos_drive_prefix mingw_cygwin_skip_dos_drive_prefix
+static inline int mingw_cygwin_is_dir_sep(int c)
+{
+	return c == '/' || c == '\\';
+}
+#define is_dir_sep mingw_cygwin_is_dir_sep
+static inline char *mingw_cygwin_find_last_dir_sep(const char *path)
+{
+	char *ret = NULL;
+	for (; *path; ++path)
+		if (is_dir_sep(*path))
+			ret = (char *)path;
+	return ret;
+}
+#define find_last_dir_sep mingw_cygwin_find_last_dir_sep
+int mingw_cygwin_offset_1st_component(const char *path);
+#define offset_1st_component mingw_cygwin_offset_1st_component
diff --git a/compat/mingw.c b/compat/mingw.c
index 34b3880b29..038e96af9d 100644
--- a/compat/mingw.c
+++ b/compat/mingw.c
@@ -350,7 +350,7 @@  static inline int needs_hiding(const char *path)
 		return 0;
 
 	/* We cannot use basename(), as it would remove trailing slashes */
-	mingw_skip_dos_drive_prefix((char **)&path);
+	mingw_cygwin_skip_dos_drive_prefix((char **)&path);
 	if (!*path)
 		return 0;
 
@@ -2275,33 +2275,6 @@  pid_t waitpid(pid_t pid, int *status, int options)
 	return -1;
 }
 
-int mingw_skip_dos_drive_prefix(char **path)
-{
-	int ret = has_dos_drive_prefix(*path);
-	*path += ret;
-	return ret;
-}
-
-int mingw_offset_1st_component(const char *path)
-{
-	char *pos = (char *)path;
-
-	/* unc paths */
-	if (!skip_dos_drive_prefix(&pos) &&
-			is_dir_sep(pos[0]) && is_dir_sep(pos[1])) {
-		/* skip server name */
-		pos = strpbrk(pos + 2, "\\/");
-		if (!pos)
-			return 0; /* Error: malformed unc path */
-
-		do {
-			pos++;
-		} while (*pos && !is_dir_sep(*pos));
-	}
-
-	return pos + is_dir_sep(*pos) - path;
-}
-
 int xutftowcsn(wchar_t *wcs, const char *utfs, size_t wcslen, int utflen)
 {
 	int upos = 0, wpos = 0;
diff --git a/compat/mingw.h b/compat/mingw.h
index 8c24ddaa3e..30d9fb3e36 100644
--- a/compat/mingw.h
+++ b/compat/mingw.h
@@ -443,32 +443,12 @@  HANDLE winansi_get_osfhandle(int fd);
  * git specific compatibility
  */
 
-#define has_dos_drive_prefix(path) \
-	(isalpha(*(path)) && (path)[1] == ':' ? 2 : 0)
-int mingw_skip_dos_drive_prefix(char **path);
-#define skip_dos_drive_prefix mingw_skip_dos_drive_prefix
-static inline int mingw_is_dir_sep(int c)
-{
-	return c == '/' || c == '\\';
-}
-#define is_dir_sep mingw_is_dir_sep
-static inline char *mingw_find_last_dir_sep(const char *path)
-{
-	char *ret = NULL;
-	for (; *path; ++path)
-		if (is_dir_sep(*path))
-			ret = (char *)path;
-	return ret;
-}
 static inline void convert_slashes(char *path)
 {
 	for (; *path; path++)
 		if (*path == '\\')
 			*path = '/';
 }
-#define find_last_dir_sep mingw_find_last_dir_sep
-int mingw_offset_1st_component(const char *path);
-#define offset_1st_component mingw_offset_1st_component
 #define PATH_SEP ';'
 extern char *mingw_query_user_email(void);
 #define query_user_email mingw_query_user_email
diff --git a/config.mak.uname b/config.mak.uname
index 3ee7da0e23..9346f67922 100644
--- a/config.mak.uname
+++ b/config.mak.uname
@@ -187,7 +187,7 @@  ifeq ($(uname_O),Cygwin)
 	UNRELIABLE_FSTAT = UnfortunatelyYes
 	OBJECT_CREATION_USES_RENAMES = UnfortunatelyNeedsTo
 	MMAP_PREVENTS_DELETE = UnfortunatelyYes
-	COMPAT_OBJS += compat/cygwin.o
+	COMPAT_OBJS += compat/mingw-cygwin.o
 	FREAD_READS_DIRECTORIES = UnfortunatelyYes
 endif
 ifeq ($(uname_S),FreeBSD)
@@ -526,7 +526,7 @@  ifneq (,$(findstring MINGW,$(uname_S)))
 	DEFAULT_HELP_FORMAT = html
 	COMPAT_CFLAGS += -DNOGDI -Icompat -Icompat/win32
 	COMPAT_CFLAGS += -DSTRIP_EXTENSION=\".exe\"
-	COMPAT_OBJS += compat/mingw.o compat/winansi.o \
+	COMPAT_OBJS += compat/mingw.o compat/mingw-cygwin.o compat/winansi.o \
 		compat/win32/pthread.o compat/win32/syslog.o \
 		compat/win32/dirent.o
 	BASIC_CFLAGS += -DWIN32 -DPROTECT_NTFS_DEFAULT=1
diff --git a/git-compat-util.h b/git-compat-util.h
index 09b0102cae..7ece969b22 100644
--- a/git-compat-util.h
+++ b/git-compat-util.h
@@ -193,10 +193,11 @@ 
 #endif
 
 #if defined(__CYGWIN__)
-#include "compat/cygwin.h"
+#include "compat/mingw-cygwin.h"
 #endif
 #if defined(__MINGW32__)
 /* pull in Windows compatibility stuff */
+#include "compat/mingw-cygwin.h"
 #include "compat/mingw.h"
 #elif defined(_MSC_VER)
 #include "compat/msvc.h"