On 22/12/2018 23:12, brian m. carlson wrote:
Thanks Brian, you helped me make some progress. I'm stuck again trying
to understand git behaviour though and wondering if there are better
ways of me seeing into git (source, debug o/p etc) than posting here.
As a reminder, I'm doing the following to create a bare repository on my
FUSE mounted decentralised storage:
cd ~/SAFE/_public/tests/data1
git init --bare blah
cd ~/src/safe/sjs.git
git remote remove origin
git remote add origin ~/SAFE/_public/tests/data1/blah
git push origin master
The bugs are in my implementation of FUSE on the SAFE storage.
I get additional output from git using the following (but it doesn't
help me):
set -x; GIT_TRACE=2 GIT_CURL_VERBOSE=2 GIT_TRACE_PERFORMANCE=2 \
GIT_TRACE_PACK_ACCESS=2 GIT_TRACE_PACKET=2 GIT_TRACE_PACKFILE=2 \
GIT_TRACE_SETUP=2 GIT_TRACE_SHALLOW=2 git push origin master -v -v \
2>&1 |tee ~/git-trace.log; set +x
Anyway, to add a little to your observations...
> What I expect is happening is that Git receives the objects and writes
> them to a temporary file (which you see in "objects/incoming") and then
> they're passed to either git unpack-objects or git index-pack, which
> then attempts to read it.
The git console output seems to confirm it is 'git index-pack' that
encounters the error, which is currently:
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), 192.43 KiB | 54.00 KiB/s, done.
Total 373 (delta 255), reused 0 (delta 0)
remote: fatal: premature end of pack file, 36 bytes missing
remote: fatal: premature end of pack file, 65 bytes missing
error: remote unpack failed: index-pack abnormal exit
To /home/mrh/SAFE/_public/tests/data1/blah
! [remote rejected] master -> master (unpacker error)
error: failed to push some refs to
'/home/mrh/SAFE/_public/tests/data/blah'
So I conclude I'm either not writing the file properly, or not reading
it back properly. I can continue looking into that of course, but
looking at the file requests I'm curious about what git is doing and how
to learn more about it as it looks odd.
I have quite a few questions, but will focus on just the point at which
it bails out. In summary, what I see is:
- The pack file is created and written with multiple calls, ending up
about 200k long.
- While still open for write, it is opened *four* times, so git has five
handles active on it. One write and four read.
- At this point I see the following FUSE read operation:
read('/_public/tests/data1/blah/objects/incoming-quFPHB
/pack/tmp_pack_E4ea92', 58, buf, 4096, 16384)
58 is the file handle, 4096 the length of buf, and 16384 the position
- Presumably this is where git encounters a problem because it then
closes everything and cleans up the incoming directory.
It seems odd to me that it is starting to read the pack file at position
16384 rather than at 0 (or at 12 after the header). I can surmise it
might open it four times to speed access, but would expect to see it
read the beginning of the file (or at position 12) before trying to
interpret the content and bailing out.
So I'm wondering what git is doing there. Any comments on this, or a
pointer to the relevant git code so I can look myself would be great.
Thanks,
Mak
