Re: problem with git push
On 20/11/2020 15.42, Mads Kiilerich wrote: > On 11/20/20 9:49 AM, Łukasz Michalski wrote: >> 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 did not expect that I need to do this step because I did not install any hooks. So when I got to the step "10. Update Git repository hooks" I ignored it thinking "hey, I do not have any hooks installed". Regards, Łukasz ___ kallithea-general mailing list kallithea-general@sfconservancy.org https://lists.sfconservancy.org/mailman/listinfo/kallithea-general
Re: problem with git push
On 21/11/2020 20.11, Thomas De Schampheleire wrote: > Hello, > > El vie., 20 nov. 2020 a las 15:50, Łukasz Michalski () escribió: >> On 20/11/2020 15.42, Mads Kiilerich wrote: >>> 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@': >> 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:// >>! [remote rejected] branch -> branch (pre-receive hook declined) >> error: failed to push some refs to 'https://' >> >> 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 >>> >> I would automate the most common path - python upgrade. >> >> Store python version somewhere in db when hooks are installed. >> Check if hooks needs reinstall on startup. > I don't think that the Python version is the crucial element here. > Rather, any change in the virtualenv path would yield this problem. > Changing the virtualenv path also has impact in other places: it > causes a new path to kallithea-cli, which has impact on e.g. the > authorized_keys file for SSH repository access. > > Having a check on startup like you suggest could perhaps be done: scan > the git hooks, authorized keys, and perhaps other places, to check > whether python and other paths point to the running instance, giving a > warning if it is not the case. > I did not change venv path. When upgrading from 3.7 to 3.8 i removed venv dir and recreated it in the same location. Then I created frontend, default config file and manually merged all changes from old config file to new one. I think that if kallithea installs it's own components in repositories then kallithea should check them on startup and try to reinstall if there is any problem. If reinstall fails then it is time to warn user. I agree that many things can change and break something, but simple python upgrade should work out of the box. Regards, Łukasz ___ kallithea-general mailing list kallithea-general@sfconservancy.org https://lists.sfconservancy.org/mailman/listinfo/kallithea-general
Re: problem with git push
Hello, El vie., 20 nov. 2020 a las 15:50, Łukasz Michalski () escribió: > > On 20/11/2020 15.42, Mads Kiilerich wrote: > > 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@': > 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:// > ! [remote rejected] branch -> branch (pre-receive hook declined) > error: failed to push some refs to 'https://' > > 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 > > > > I would automate the most common path - python upgrade. > > Store python version somewhere in db when hooks are installed. > Check if hooks needs reinstall on startup. I don't think that the Python version is the crucial element here. Rather, any change in the virtualenv path would yield this problem. Changing the virtualenv path also has impact in other places: it causes a new path to kallithea-cli, which has impact on e.g. the authorized_keys file for SSH repository access. Having a check on startup like you suggest could perhaps be done: scan the git hooks, authorized keys, and perhaps other places, to check whether python and other paths point to the running instance, giving a warning if it is not the case. /Thomas ___ kallithea-general mailing list kallithea-general@sfconservancy.org https://lists.sfconservancy.org/mailman/listinfo/kallithea-general
Re: problem with git push
On 20/11/2020 15.42, Mads Kiilerich wrote: > 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@': 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:// ! [remote rejected] branch -> branch (pre-receive hook declined) error: failed to push some refs to 'https://' 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 > I would automate the most common path - python upgrade. Store python version somewhere in db when hooks are installed. Check if hooks needs reinstall on startup. (sorry for top-posting in previous reply) Regards, Łukasz ___ kallithea-general mailing list kallithea-general@sfconservancy.org https://lists.sfconservancy.org/mailman/listinfo/kallithea-general
Re: problem with git push
I would automate the most common path - python upgrade. Store python version somewhere in db when hooks are installed. Check if hooks needs reinstall on startup. Regards, Łukasz On 20/11/2020 15.42, Mads Kiilerich wrote: > 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@': 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:// ! [remote rejected] branch -> branch (pre-receive hook declined) error: failed to push some refs to 'https://' 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
Re: problem with git push
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@': 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:// ! [remote rejected] branch -> branch (pre-receive hook declined) error: failed to push some refs to 'https://' 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
Re: problem with git push
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@': >> 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:// >> ! [remote rejected] branch -> branch (pre-receive hook declined) >> error: failed to push some refs to 'https://' >> >> 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! Before discovering this issue I changed repository group for this repo from GroupA to GroupB and then from GroupB to GroupA. I also upgraded kallithea to 0.6.2 changing python version from 3.7 to 3.8 (by creating new venv). Regards, Łukasz ___ kallithea-general mailing list kallithea-general@sfconservancy.org https://lists.sfconservancy.org/mailman/listinfo/kallithea-general
Re: problem with git push
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@': 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:// ! [remote rejected] branch -> branch (pre-receive hook declined) error: failed to push some refs to 'https://' 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 ___ kallithea-general mailing list kallithea-general@sfconservancy.org https://lists.sfconservancy.org/mailman/listinfo/kallithea-general
