| # based on the following: | |
| # http://saintgimp.org/2013/01/22/merging-two-git-repositories-into-one-repository-without-losing-file-history/ | |
| # http://blog.caplin.com/2013/09/18/merging-two-git-repositories/ | |
| git clone repo_main | |
| git clone repo_sub | |
| cd repo_main | |
| git remote add repo_sub ../repo_sub | |
| git fetch repo_sub |
| # Install/update SOPS to latest on Fedora - https://github.com/mozilla/sops | |
| echo "[+] Install/upgrade SOPS" | |
| SOPS_VERSION=$(curl -s https://api.github.com/repos/mozilla/sops/releases/latest | jq .tag_name | tr -d '"') | |
| dnf install -y https://github.com/mozilla/sops/releases/download/${SOPS_VERSION}/sops-${SOPS_VERSION}-1.x86_64.rpm | |
| sops --version | |
| # sops 3.2.0 (latest) |
The connection failed because by default psql connects over UNIX sockets using peer authentication, that requires the current UNIX user to have the same user name as psql. So you will have to create the UNIX user postgres and then login as postgres or use sudo -u postgres psql database-name for accessing the database (and psql should not ask for a password).
If you cannot or do not want to create the UNIX user, like if you just want to connect to your database for ad hoc queries, forcing a socket connection using psql --host=localhost --dbname=database-name --username=postgres (as pointed out by @meyerson answer) will solve your immediate problem.
But if you intend to force password authentication over Unix sockets instead of the peer method, try changing the following pg_hba.conf* line:
from
See stackoverflow and https://ipython.readthedocs.io/en/stable/install/kernel_install.html
In your project folder:
pipenv install ipykernel
pipenv shellThis will bring up a terminal in your virtualenv like this:
| % !TEX TS-program = xelatex | |
| % !TEX encoding = utf-8 | |
| % !TEX root = ../mythesis.tex | |
| % !TEX spellcheck = en-US % en-GB, de-DE | |
| % !BIB TS-program = biber |
| # -*- coding: utf-8 -*- | |
| """Demonstrate high quality docstrings. | |
| Module-level docstrings appear as the first "statement" in a module. Remember, | |
| that while strings are regular Python statements, comments are not, so an | |
| inline comment may precede the module-level docstring. | |
| After importing a module, you can access this special string object through the | |
| ``__doc__`` attribute; yes, it's actually available as a runtime attribute, | |
| despite not being given an explicit name! The ``__doc__`` attribute is also |
| git branch -m old_branch new_branch # Rename branch locally | |
| git push origin :old_branch # Delete the old branch | |
| git push --set-upstream origin new_branch # Push the new branch, set local branch to track the new remote |
#Heading 1 ##Heading 2 ###Heading 3 ####Heading 4 #####Heading 5 ######Heading 6
Paragraph