I'm a git, you're a git, everyone's a git, git

by Mike Levin

Friday, May 20, 2022

This is one for the history books. I have taught my wife enough Linux to load vim and enough vim to write Python.

But what about git? Hmmm. I used to think that one should take up Python first through Jupyter Notebooks, then put off Linux, vim & git for as long as necessary until the time is right. Then Microsoft fixed the WSL install on Windows 11 to merely just be:

wsl --install

Then I realized the age of easy-install Linux was upon us. It can be done under a still-working version of Windows, so you have all your drivers, device support, game compatibility and whatnot. There’s no searching around, making decisions, choosing Linux versions. About the only decision is whether you type that command from a DOS Command window (COM) or a Windows Powershell. Either will do the trick perfectly well. But after the command finishes, you’ll have Ubuntu 20.04 (as of the time of this writing) installed and running right in the window you ran the command from.

So, things are different. It is no longer necessary to defer the Linux and vim part of the experience. Quite the contrary, the vim part of the experience is so very challenging, central and pivotal to making the transition to… what? Another kind of human being in the same way engineers, musicians and athletes are other kinds of human beings, that the sooner you begin this transformation, the better. The only reason I deferred this transformation in the past is because of how hard it was to get an everyday Linux system. Before Windows 11, the wsl –install step still had a few show-stopping steps that followed, namely turning on the hypervisor and doing a few reboots. It was too difficult for the mainstream. It is not anymore.

vim is too difficult for the mainstream, you say? Yeah, Microsoft’ll have you believe that. They bought Github, built-in Linux and hired the creator of Python. But what are they going to do about vim? Crush it with VSCode, of course! You will use VSCode. You can depend on that. Microsoft needs you to depend on that, for if you learn vim, you will have a viable path to platform-independence, and that can not be allowed.

So get your ass to vim! Do it now! It’s already installed on your machine. Run, Forrest, run! Use vim and don’t ever look back!

Once you’re on vim through WSL, you’re already on Linux. Use vim to make a file:

vim hello.py

From inside the file, learn enough vim to write and save:

print("Hello World!")

The keystrokes by the way are:

i
print("Hello World!")
[Esc]
:wq
[Enter]

Okay, now from the command-line that you’ve returned to, type:

python hello.py

Hit Enter, of course. It shouldn’t need to be said, but after venturing into vim for maybe the first time, I guess it does have to be said. A lot of assumed keystrokes in everyday instructions have to become considerably more precise when discussing vim.

And you’ll see the output of your Hello World program. Okay, so now you know Linux, Python and vim.

But what about git?

Honestly, git’s the hardest of my recommended set of tools now. Sure, Linux, Python and vim have so very, very, very, very, very much more to explore and learn. But look, you can be functional with all three in just a single sitting.

wsl --install
echo "print('Hello World!') > hello.py
python hello.py
vimtutor

Okay, so now you know Linux, Python and vim. The rest is details.

But there’s nothing like this for git. git eludes. git is still mysterious.

git builds upon assumed Linux knowledge that one might not have.

git requires initialization.

git requires initiation.

Put off git until the time is right.

Nervousness, tap, tap, tap… all that code not backed up. No undo. No ability to flow it onto other computers. A laptop crash would be devastating… tap, tap, tap… still, no git?

But when will the time be right?

What’s that Nat? You want to web-publish like I do?

Well, I guess the time has come the Walrus said to speak of that great and awesome git’s other main contribution to the free and open source world. This massive git of git’s first and largest contribution of course being Linux itself. Linus Torvalds wrote git. Linus named it after himself.

This is appropriate given Linus’ awesome creativity inventing the product from scratch, as Ken Thompson, the creator of Unix, will tell you about Linus and Linux and Bitkeeper’s creator Larry McVoy will tell you about git. I am quite sure Larry called Linus a git before Linus named git git.

At least Linus knows himself well. However, this wants me want to bang my:

git reset --hard HEAD^^^^^^^^

But I get ahead of myself. Let’s keep the geek jokes to a minimum. They only infuriate those sincerely trying to learn.

Nat asks to web publish like me. Okay, so it’s time to teach her…

Github Pages!!!

Okay, take a deep breath. You thought Linux, Python and vim were challenging. Okay, let’s just start with Github Pages. Why? Because:

It lets you publish markdown as web pages (no HTML-knowledge necessary)
Creating a markdown is quick and easy in vim.
It forces us to learn enough git to make a local “repository”
It forces us to get that repository up on Github
Then your website is just a few Github / Settings away.

Okay, assume being in a Linux terminal but with little Linux experience, either on operation or terminology. It can all be rather intimidating and overwhelming, so break it down Barney-style.

First is explaining what a git “repository: is.
Next is explaining what the git program itself is.
Then we have to explain what using a command-line program in a terminal is.

Okay, here we go:

git is a command-line program (probably already on your machine)
We have to check if it actually is on your machine.
- It usually is on recent versions of Linux (which you are on)
To check if we have git:
- Open a Terminal, which is also known as:
  - A shell
  - The command-line interface
  - CLI
- As an aside, the Window versions which are similar but not Linux, are:
  - COM (the command window)
  - Powershell
- None of this will work from the Windows versions
- You can tell the difference between them based on their prompt
  - Both COM and Powershell use the greater-than “>” as their prompt
  - Linux uses the dollar-sign “$” as its prompt

Aside from very few special cases, I am never talking about COM or Powershell. These have very little use except to install Windows software. We used COM to install Linux with the wsl –install command. That’s the last we should ever have to use COM or Powershell as far as I’m concerned.

But we now have the Linux command-line. The preferred way to get to the Linux command-line (a.k.a. Terminal, Shell or CLI) is through the new Windows Terminal program, available through the Microsoft Store.

I am about to show you how to use the git program from the Linux command-line.

So we have a Linux command-line open and ready to use. We have it by running Microsoft Terminal. Our default is set to Ubuntu 20.04. If it’s not, change the default to Ubuntu 20.04. That way whenever we want a Linux terminal, we open Microsoft Terminal and it’s instantly there.

Go to your Linux command-line.

The next step is to show you how to read the git –help without needing to scroll-up. We have turned off the ability to scroll-up in a Linux command-line so that vim doesn’t get messed up with the scroll-wheel. This is a good thing and we should keep it that way.

To show git help, we type:

git --help | less

Now we are displaying the output of git –help, but we are “piping” it through the program called “less”.

The above command should be read as: show git’s help, but pipe its output to the program called less.

Piping is sending the output of one program into the input of another program. This allows us to read all the help easily, even if it’s taller than the screen.

What would normally “scroll past” us and be lost off the top of the screen is now all sent into a program that lets you navigate the text with the same keys vim uses, including the q key to get exit the “less” program.

Okay, a word about how git “fits into” the overall picture.

The tools I use are really just 4 (plus Jupyter), so 5, really. But Jupyter is for learning. The first 4 I expect I’ll be using till the day I die.

Linux
Python
vim
git

git is important because your files must be:

In more than one place
Optionally very, very secret. To your satisfaction… enough for a journal. Why?
- Because Microsoft bought Github
- Github is the most popular place for git repos
- Microsoft has their reputation and stock value on the line
- A leak of private info that is their fault will be on the front page of the newspapers the next day and make their stock value plummet, lose customers, lose faith, and begin an inevitable downfall of the company.
- Microsoft will not intentionally let private repos leak.
- Much more than a person’s private journal is at stake. Proprietary code worth millions or billions is kept this way, too.
- It is easier these days for your local machine to be hacked than for Microsoft to screw up with this.

What is a git repo, or “repository”?

It is a folder (a.k.a. directory). Those words are interchangeable.

The Linux command to make a folder (a.k.a. directory) is mkdir

When you run mkdir, it makes the directory in the location where you are in the command-line.

So you want to look at where you are to make sure it’s where you want the folder to be made, and you can do that with:

pwd

pwd means path of working directory.

The first step is to find out where the Operating System compels you to be. It’s always easy to start there.

From that location, I create a github folder.

After starting up your computer, it is a “blank slate”. Nothing is running.
When you run a Terminal (a.k.a. command-line, shell or CLI), you are “home”
When you run pwd, you will see that home is /home/ubuntu/
- This is where the (Linux) OS “compels” you to be… home.
- It is from here, you mkdir… but with good nicknames.
- The most important nickname in my mind is github.

So open a terminal and type:

mkdir github

This is already done.

Now we can:

cd github

To make ourselves “inside” the github folder.

From inside the github folder, we can make new directories.
The names are important because those are about to be “repos”.
Repos start out as ONLY git repos on your own (local) computer.
Even when it’s on Github, it can STILL be kept private (but not published as a website if you’re using free Github)
- Github lets you keep a few private repos
- But you cannot share other people into them
- And you cannot turn them into Github Pages websites
For our purposes, we will need a public repo.

So we cd into github

Then we mkdir on a name that will soon be a public repo.

mkdir publishme
cd publishme
git init
ls
ls -a

You can see that there is a “hidden” .git folder made as a result of git init.

vim index.md

This is the preferred file-name for a homepage under the Github Pages publishing system. Write some markdown.

git status
git add index.md

There is now a .git folder in this location. In the next step, we:

Go to github.com
We select the + in the upper-right and select “New repository”
We put our cursor in the Repository name box and type the exact same name as the folder we’re working from on our local computer.
We scroll down and we hit “Create repository”

We go back to the command-line and type:

git commit -am "My first commit"
git config --global user.email "youremail@somewhere.com"
git config --global user.name "Your Name"

In the above instructions the git config commands only have to be done once per computer.

We’re almost there.

git branch -M main
git remote add origin git@github.com:gitusername/publishme.git

This reaches a point where some special public/private key (file) generation must be done. Usernames and passwords don’t work anymore on a git push.

Of the work we’ve done so far, there’s definitely 2 separate parts:

That which is 1-time startup stuff
That which is recurring every time stuff

It is time to figure out how to get rid of passwords on git.

cd ~/.ssh

If it doesn’t exist, make it.

mkdir ~/.ssh
cd ~/.ssh

From inside ~/.ssh:

ssh-keygen -t rsa -C "email@address.com"

Hit Enter to keep the answers blank, which is fine.

Check git origin with:

git remote -v

Set the remote origin to have the username in it. All git repos on your computer (local) in preparation for going onto a website like Github (remote as in elsewhere) need to have that elsewhere-location set. The below example is an actual real-world example. It’s nuts, but it really is git@github.com:[username]. The username being embedded tells it from which Github user it should look for a public key. Therefore we are going to have to generate a public key and put it on Github.

git remote set-url origin git@gihub.com:miklevin/pipulate.git

Conceptually, we got to the end in our earlier session. This last step of pushing shows that “authentication” (like username/password) is so often the most difficult part of an entire process.

Because Microsoft is fighting against hacking, they locked down the security on Github. Using a username and password is no longer possible on things like:

git push

For the same reason sites are insisting on 2-factor authentication these days, Github is insisting on better security. Using a username and password is actually less secure than alternatives that involve public/private key files. These keys live in a very standard location on Linux. That location is:

~/.ssh

This is the same as:

/home/ubuntu/.ssh

The dot before the folder-name makes the folder “invisible” just like a .vimrc file. It’s not supposed to show up in a normal:

ls

…listing of a folder’s contents. But it will show if you use:

ls -a

…because the “-a” forces Linux to show “all” files, including those starting with a period “.”

So, then we have to actually generate those keys. The get created with a command-line program called ssh-keygen. Like “git”, ssh-keygen was already on your Linux. This is because these tasks are so so common these days that most modern Linux like Ubuntu 20.04 which you’re using have it pre-installed. So you don’t have get it.

The command we used is:

ssh-keygen -t rsa -C "email@address.com"

Of course replace the email with the one you use for Github.

This command prompts you 3-times for things. None of them are important. You don’t need that level of security. So by just hitting Enter to each of the questions, you will end up with 2 keys in that folder:

id_rsa
id_rsa.pub

The first one is the secret part of the key. It does not get given out. It stays on your machine. It’s no big loss if you really lose it one day, because you can regenerate a new public/private-key pair. That’s what these are. And you would just put the new public key where it goes, Github, for example.

So the CONTENTS of the public key named id_rsa.pub is going to go onto Github.

Once it’s there, this command will work, although you will have one more “yes” to answer if everything is done correctly. After that yes, you will be able to just “git push” whenever you like. The first git push has to be this (after you’ve added the public key to Github).

git push -u origin main

When a folder is turned into a git repo with the git init command, many things are not set yet.

If it’s the first time using git on that machine, some of these settings are “global”, meaning not for the repo in particular, but for your whole Linux system.

When first we tried anything that actually tried connecting to Github, we started getting challenged to meet its requirements, including setting our email and name. Those commands it made us do were:

git config --global user.email "email@gmail.com"
git config --global user.name "Your Name"

Of course, replace with your own.

Now the “global” in these commands meant (as I NOW know) a .gitconfig file was created in home, a.k.a. ~/.gitconfig a.k.a. /home/ubuntu/.gitconfig, and as such can be edited with:

vim ~/.gitconfig

…which contains:

[user]
    email = email@gmail.com
    name = Your Name

That is just an FYI, little bonus. It was the first challenge of connecting to Github. The 2nd challenge was much bigger because it first demanded a username and password, and then told us that was not good enough, starting August of 2021.

To get the public key onto Github:

cd ~/.ssh
less id_rsa.pub

Use your mouse pointer to click-drag from the beginning to the end (including your email address). This requires Windows Terminal to be set up for click-dragging to copy into the Windows OS copy/paste buffer. This is a very good idea. Do it.

Next, you go to Github / settings / SSH and GPG keys

Click New SSH Key.

Give it a title like “My Key”

Paste the public key text into the Key field

Click Save SSH Key

Now the command:

git push -u origin main

…will work. Almost there! Remember to answer “yes” to the question that pops up. It will add github to a “known_hosts” file in ~/.ssh. You can go look at it with vim because it’s sometimes necessary to delete lines out of there.

Last (after a successful push):

Go to Github / Repository you want to publish as a website
Go to Github / Settings (for the Repo) / Pages
Select Source Branch: main
Hit Save

Your site is punished. It will give you the link.

From here on out:

Edit index.md
git commit -am “Something”
git push

Git pushing will go smooth from here on out.

New files can be added, but you must also git add and commit them as well.

Refer to Jekyll documentation, especially regarding “Front Matter” to control details like title tags and URL it gets published on.