git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Re: [PATCH] config.mak.uname: Cygwin: Use renames for creation

From
Johannes Schindelin <johannes.schindelin@gmx.de>
Date
Aug 9, 2015, 09:01 UTC
Message-ID
<058a7756ada2fa5043ca9b910d6e1543@www.dscho.org>
In-Reply-To
<CA+kUOa=KRBSKDqWUj2RiO45PqVYGmN+yqG426jtUoXayxGkduw@mail.gmail.com>
Hi Adam,
On 2015-08-09 04:01, Adam Dinwoodie wrote:
> I do not see any difference between the situation here and the situation
> for MinGW, which is fundamentally a Cygwin fork, but which already has
> this build option set for it in config.mak.uname.
This is incorrect. MinGW is distinctly *not* a Cygwin fork. MinGW means "Minimal GNU on Windows" and that in turn means that it provides an environment to build executables that purely use the Win32 API. Read: no POSIX emulation whatsoever. Most notably, MinGW programs cannot use fork(2); It is simply unavailable.
What you *probably* meant is that Git for Windows relies on MSys2 for its shell and Perl scripts, and that MSys2 in turn is a fork of Cygwin. That affects *only* the scripts, though; Git itself (as in `git.exe`) is still a pure MinGW program (and as a consequence, is quite a bit faster than Cygwin Git, at the price of certain quirks that Cygwin Git does not suffer).
Show 17 quoted lines
>> We've gotten a lot of users on the list who ask why their Git
>> directories on shared drives aren't working (or are broken in some way).
>> Since I don't use Windows, let me ask: does the Cygwin DLL handle
>> link(2) properly on shared drives, and if not, would this patch help it
>> do so?  I can imagine that perhaps SMB doesn't support the necessary
>> operations to make a POSIX link(2) work properly.
> 
> I'd need to go back to the Cygwin list to get a definite answer, but as
> I understand it, yes, this is is exactly the problem -- quoting Corinna,
> one of the Cygwin project leads, "The MS NFS is not very reliable in
> keeping up with changes to metadata."
> 
> We have verified that setting `core.createobject rename` resolves the
> problem for people who are seeing it, which very strongly implies that
> this build option would solve the problem similarly, but would fix it
> for all users, not just those who spend enough time investigating the
> problem to find that setting.
>From my experience, it appears that providing Corinna Vinschen (or better put: the Cygwin developers in general) with a sound patch gets things fixed pretty timely.
And since `core.createObject = rename` seems to work around the problem, it should be possible to patch the Cygwin runtime accordingly. Sure, it will take a little investigation *what* code should be changed, and how, but the obvious benefit to *all* Cygwin applications should make that effort worth your while.
Please note that Cygwin's source code itself is in Git now, too: https://cygwin.com/git.html

Ciao, Johannes

Previous: Adam DinwoodieNext: Adam Dinwoodie
Message 5 of 9 in “config.mak.uname: Cygwin: Use renames for creation”
  1. config.mak.uname: Cygwin: Use renames for creationAdam Dinwoodie, Aug 7, 2015
  2. Mark LevedahlAug 8, 2015
  3. brian m. carlsonAug 8, 2015
  4. Adam DinwoodieAug 9, 2015
  5. Johannes SchindelinAug 9, 2015
  6. Adam DinwoodieAug 9, 2015
  7. Junio C HamanoAug 10, 2015
  8. Adam DinwoodieAug 11, 2015
  9. Johannes SchindelinAug 18, 2015

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.