Re: Git force push fails after a rejected push (unpack failed)?

[Johannes Sixt <j6t@kdbg.org>]

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