= phenomenon = In setting up /project/armv8, one of the reasons was to be able to host a very large git repository (but not likely to be long lived). rootfs.git is currently about 1.5G and expected to continue growing.
However, if I use the clone command given in the summary, I get a 'Cloning into rootfs' message and nothing else -- no rootfs directory is created or populated locally and a return status from the command is errno 128 (EKEYREVOKED?). If I use git: instead of http:, I get 'fatal: The remote end hung up unexpectedly' instead.
= background analysis = Well, you can see the symptoms. I am at a loss as to why this does not work. I have tried soft- and hard-links to other locations (e.g., my ~/public_git to /project/armv8, and vice versa) but end up having to cross file system boundaries, which git will not do.
= implementation recommendation = Should this be on fedorahosted.org instead?
Thanks for any help/pointers you might have.
so I can make the path work via http:// git clone - but not right now via git://
to make it work via http:// do:
cd /project/armv8/rootfs.git run: git update-server-info
touch: git-daemon-export-ok
clone via http:// as you'd expect
the issue with git:// cloning is an selinux one and not yet resolved.
The new http proto should be about as fast as the git one... so will this meet your needs?
Or should we try and get git working for any reason?
okay - I think I have git:// working now.
please add git-daemon-export-ok to your dir and try cloning via git:// again.
thanks
okay - so - I spoke too soon git:// is not working.
clone via http:// as that should continue to work. In the future, with some selinux policy changes we maye be able to get git:// working again. But not at this moment.
Thanks for all the research and effort. My apologies for not getting back to you sooner -- I'm supposed to be on holiday :).
As far as I'm concerned, http:// is just fine. Having git:// would be nice, but is not required, nor essential.
cool.
Login to comment on this ticket.