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