PennyMonkey 2021-01-20

Creating a new Git Repository: Master/Main issues

I had a local git repo that I needed to connect and push to a new remote repo. First, I created the new remote repo via the web interface and initialized it with a license file. Then I came back to my existing local repo, that was newly created as well with "git init", and issued the following commands: ~$ git remote add origin https://github.com/ erikamart/myrepo.git ~$ git branch -M main ~$ git push -u origin main The last push command caused the error that said there were remote changes (i.e. the new remotely made license file) that needed to be fetched and merged in first. OK, so I did--> ~$ git pull origin main Unbeknownst to me, this automatically created a new branch called "main" to pull in the remote changes while still keeping my local branch that was defaulted to be called "master". So when I tried to "git push" again, it sent 2 branches called "main" & "master" to the remote repo. In the remote web interface I was forced to complete a pull request to merge the "master" into the "main" branch and then I deleted the "master" branch since it was no longer needed. Then on my local repo, every time I tried to "git pull" to merge the changes made in the web interface, I would get the error: "Your configuration specifies to merge with the ref 'refs/heads/master' from the remote, but no such ref was fetched." This meant that even though I deleted the "master" branch, I did not locally delete the "remote-tracking branch" and reset the upstream tracking information off the now gone "master" branch. The solution ended up being to use the following commands to fix it: 1. View just remote-tracking branches --> ~$ git branch -remote >> origin/main 2. Check the local repo status and reset the tracking info --> ~$ git status ~$ git branch --unset-upstream ~$ git branch --set-upstream-to=origin/main 3. Remove obsolete local remote-tracking branches for remote branches that no longer exist --> ~$ git fetch origin --prune

PennyMonkey 2021-01-14

Metaphor: How do you eat an elephant?

I once had a very insightful and motivating instructor that gave the best advice I've ever heard. He knew the class was getting frustrated and discouraged with the ton of information he was throwing our way. So he gave us the simplest, most comprehensible, advice I'll never forget. He said, "Think of everything you have to get done and learn as....an elephant. An elephant is a very large animal. Now pretend you have to figure out how to eat all of that elephant. How do you eat an elephant? The whole elephant. Sounds impossible, doesn't it? It's not impossible. Don't focus on the large thing in front of you and freak out, focus on tiny bits at a time and keep at it. Before you know it, you're all done. So how do you eat an elephant? A little bit at a time!"

PennyMonkey 2021-01-14

Using SSH key passphrases

It is highly recommended to set a passphrase during the generation of an SSH key. However, this then means that you have to enter that passphrase every time you use the ssh key; UNLESS you add that key to an ssh-agent. Configure an authentication agent to handle your passphrase so you can keep it secure and don't have to enter it for each use. However, this is done differently between systems. So here's what happened to me: I generated a key + passphrase on a Linux system and didn't add it to an ssh-agent. After getting annoyed by having to use the passphrase all the time, I decided to remove it via command line. The following will decrypt the private key file and write it to a new temp file that would be used to overwrite the original encrypted private key file--> ~$ openssl rsa -in <Encrypted key filename> -out <Unencrypted key filename> ~$ mv <Unencrypted key filename> <Encrypted key filename> Months later, on a Mac OS, I generated a key + passphrase, sans ssh-agent, and got annoyed with the constant passphrase entry. So when I tried my previous solution above, I received this error: "unable to load Private Key 140736254190536:error: 0906D06C:PEM routines: PEM_read_bio:no start line: /BuildRoot/Library/ Caches/ com.apple.xbs/ Sources/libressl/ libressl-22.50.3/ libressl/ crypto/pem/ pem_lib.c:704: Expecting: ANY PRIVATE KEY". Extensive web searches to fix the issue did not help. While addressing a similarly related issue, I came across the proper way to set all this up! Thanks GitHub! Link--> https://docs.github.com/ en/free-pro-team@latest/ github/authenticating-to-github/ working-with-ssh-key-passphrases Saving a passphrase to the keychain on Mac OS--> ~$ eval "$(ssh-agent -s)" > Agent pid <some numbers> ~$ open ~/.ssh/config ~$ nano ~/.ssh/config >> Host * AddKeysToAgent yes UseKeychain yes IdentityFile ~/.ssh/<private key filename> ~$ ssh-add -K ~/.ssh/<private key filename> **************************** For Linux it's much simpler--> ~$ eval "$(ssh-agent -s)" > Agent pid <some numbers> ~$ ssh-add ~/.ssh/<private key filename>

PennyMonkey 2021-01-05

When VPN is the Devil!

Here I am testing, and testing, and testing my code to troubleshoot issues that connect to other service API's. It starts to seem that every solution I try doesn't work. One in the hundred should work; right!? Everybody says there's a solution, but it's not working and it HAS to work. Everything I try results in absolutely no changes in the outcome. I'm starting to go insane. Hours later and feeling no closer to a solution then at the start......something different happens. My wifi starts getting wonky so I decide to reboot my service. In that process I disable my always running VPN with the intention of bring it back on, but first I need to eat some chocolate to soothe my hanger. In my distraction of the sugar rush I forget to turn my VPN on and rerun my last made test that previously failed. (because the definition of insanity is doing the same thing over and over while expecting different results). With the last ounce of my sanity, I blink....suddenly the stars align, the gods smile upon me, and a baby unicorn is born....BAM, the test actually works! I try it again and it works. Again and it works. Again, successful. I'm dumbfounded. I didn't know why it wasn't working before and I don't know why it's working now. I go through my checklist of setup and it's all the same as I've had for a 1,000 failed tests but now the test is successful. Then it dawns on me. The one variable that's different. The one variable that I KNEW has been a culprit before......THE VPN IS OFF! Yea, excuse me while I scream silently into a pillow. -_-

1 2 3