Am 07.07.2015 um 21:49 schrieb Jeff King:
On Tue, Jul 07, 2015 at 09:31:25PM +0200, X H wrote:
For the moment, I'm the only one pushing to the remote, always with
the same user (second user is planned). I use git-for-windows which is
based on MSYS2. I have mounted the network share with noacl option so
permissions should be handled by the Windows share. I'm in a group
which has read/write access. I have not configured
core.sharedrepository, I don't think it is useful with noacl since
unix group are not used in this case. The permission for the folder
above the file with permission denied is rw, but this file is read
only so if git try to modify it it won't work.
Ah, so this is not a push to a server, but to a share mounted on the
local box?
That is leaving my realm of expertise. I'm not sure if it could be a
misconfiguration in your share setup, or that git is trying to do
something that would work on a Unix machine, but not on a Windows share.
You might want to ask on the msysgit list:
https://groups.google.com/forum/#!forum/msysgit
Why does git try to write a file with the same name? If I amend a
commit isn't the sha modified?
Yes, but remember that git stores all of the objects for all of the
commits. So for some reason your push is perhaps trying to send an
object that the other side already has. Usually this does not happen
(the receiver says "I already have these commits, do not bother sending
their objects"), but it's possible that you have an object that is not
referenced by any commit, or a similar situation. It's hard to say
without looking at the repository.
After a non-fast-forward push fails, a subsequent forced push sends the
same set of objects, which are already present at the server side, but
are dangling objects.
Apparently, Git for Windows fails to replace the read-only files that
live on the network file system.
I have observed this recently, as well. I haven't dug into the detailed
failure mode, yet. In my case, I have a daily repack running on the
server side (it's a Samba share on a Linux box), that garbage-collects
the dangling objects. Usually, the next day the forced push is
successful. I know this is not very helpful if you can't wait a day for
the next push attempt...
-- Hannes
--
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