On 11/20/20 9:49 AM, Łukasz Michalski wrote:
On 19/11/2020 20.53, Mads Kiilerich wrote:
On 11/19/20 4:31 PM, Łukasz Michalski wrote:
Hi,
I have a problem with one of git repos. When I try to push changes I got "remote
rejected":
[zork@serenity filebench]$ git push zork
Password for 'https://zork@XXXXXXXXXXXX':
Enumerating objects: 15, done.
Counting objects: 100% (15/15), done.
Delta compression using up to 8 threads
Compressing objects: 100% (8/8), done.
Writing objects: 100% (8/8), 3.17 KiB | 1.58 MiB/s, done.
Total 8 (delta 7), reused 0 (delta 0), pack-reused 0
To https://XXXXXXXXXXXX
! [remote rejected] branch -> branch (pre-receive hook declined)
error: failed to push some refs to 'https://XXXXXXXXXXXX'
Kallithea 0.6.2 on Arch Linux.
What can I do to resolve this issue? I already tried to increase log level but
I cannot find any clues in logs.
It works for other repos - just not this one?
The pre-receive hook is really not doing anything and should never reject
pushes. I guess the hooks (for this repo?) isn't installed correctly? Inspect
and compare hooks/post-receive for working and non-working repos. Or try to
reinstall all hooks in Admin/Settings/Remap and Rescan/Install Git hooks +
Overwrite existing Git hooks.
It might be a very fundamental problem (such as finding the right Python
interpreter to run the hook) so I doubt Kallithea logging could say anything.
But perhaps the web server error log has something.
/Mads
Rescan+Overwrite helped. Thanks!
I also upgraded kallithea to 0.6.2 changing python version from 3.7 to 3.8 (by
creating new venv).
Great it works.
Should the documentation be improved to clarify the importance of
re-installing git hooks after upgrading Kallithea or Python? Where and
how would you suggest phrasing it?
I don't know how we can improve this handling. We rely on Git
functionality. If you modify hooks/pre-receive to invoke sys.stdin.write
or sys.stderr.write or cause an exception (for example by adding an
invalid import), you will see that as "remote:" lines on the client
side. But if you modify the first line with #! to point at something
that doesn't work, Git will be silent - not even a "bad interpreter"
message as the shell would do.
We could perhaps change the hooks to *always* write something, such as
"rejected by Kallithea hook" or "accepted by Kallithea hook" ... and if
there is no such message, we can know that the hook failed badly. But
that wouldn't be explicit and obvious ... and we did figure it out anyway.
/Mads
_______________________________________________
kallithea-general mailing list
kallithea-general@sfconservancy.org
https://lists.sfconservancy.org/mailman/listinfo/kallithea-general
