Does "git push" open a pack for read before closing it?
[Major ignorance alert]
I'm writing software to implement a FUSE mount for a decentralised file
system and during testing with git I see some strange behaviour which
I'd like to investigate. It might be a bug in my code, or even the FUSE
lib I'm using, or it might be intended behaviour by git.
So one thing I'd like to do is check if this is expected in git.
OS: Ubuntu 18.10
git version 2.19.1
Decentralised storage mounted at ~/SAFE
What I'm doing
I'm testing my FUSE implementation for SAFE Network while exploring the
use of git with decentralised storage, so not necessarily in a sensible
arrangement (comments on that also welcome).
I have a folder at ~/SAFE/_public/tests/data1/ and want to create a bare
repo there to use as a remote from my local drive for an existing git
repo at ~/src/safe/sjs.git
Anyway, I do the following sequence of commands which are all fine up
until the last one which eventually fails:
git init --bare blah
git remote remove origin
git remote add origin ~/SAFE/_public/tests/data1/blah
git push origin master
Here's the output from the last command above:
Enumerating objects: 373, done.
Counting objects: 100% (373/373), done.
Delta compression using up to 8 threads
Compressing objects: 100% (371/371), done.
Writing objects: 100% (373/373), 187.96 KiB | 33.00 KiB/s, done.
Total 373 (delta 254), reused 0 (delta 0)
remote: fatal: unable to open
Remote I/O error
error: remote unpack failed: index-pack abnormal exit
! [remote rejected] master -> master (unpacker error)
error: failed to push some refs to '/home/mrh/SAFE/_public/tests/data1/blah'
Inspecting the logs from my FUSE implementation I see that there's a
problem related to this file on the mounted storage:
Prior to the error the file is written to multiple times by git - all
good (about 200kB in all). Then, before the file is closed I see an
attempt to open it for read, which fails. The failure is because I don't
support read on a file that is open for write yet, and I'm not sure if
that is sensible or what git might be expecting to do given the file has
not even been flushed to disk at this point.
So I'd like to know if this is expected behaviour by git (or where to
look to find out), and if it is expected, then what might git expect to
do if the file were opened successfully?
N.B. After the failure, the file is closed and then deleted!
Also note that it is possible the behaviour I'm seeing is not really git
but another issue, such as a bug in the sync/async aspect of my code.
Secure Access For Everyone:
- SAFE Network
- First Autonomous Decentralised Internet