On Sat, Aug 08, 2015 at 09:06:28PM +0000, brian m. carlson wrote: > On Sat, Aug 08, 2015 at 04:47:46PM -0400, Mark Levedahl wrote: > > On 08/07/2015 04:30 PM, Adam Dinwoodie wrote: > > >When generating build options for Cygwin, enable > > >OBJECT_CREATION_USES_RENAMES. This is necessary to use Git on Windows > > >shared directories, and is already enabled for the MinGW and plain > > >Windows builds. > > > > I've been supporting use of git on cygwin since about 2008, this issue has > > never risen that I know. Whatever issue is being patched around here, if > > truly repeatable, should be handled by the cygwin dll as that code is > > focused on providing full linux compatibility. If git on linux does need > > this patch, git on cygwin should not, either. So, I vote against this. There has been recent and historical discussion on the Cygwin mailing list about this problem, as well as in other places like Stack Overflow. I've put a link to one of those discussions on the Cygwin mailing list in the original patch email. I can also see some discussiions on this list that seem related (search archives for "failed to read delta-pack base object" and "Cygwin"). It may be the technically correct approach that the Cygwin library ought to fix this, and indeed some improvements have been made in this area. However given the limited interfaces that Windows offers here, a final fix is very unlikely to come any time soon, so this patch is the pragmatic solution. 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. > 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. Adam -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html