Remember Git passwords securely

Typing your password again and again when using git with remote repo is tiring.

Git will integrate with your OS-level password storage easily enough though.

Macs

I'm under the impression that on Macs, it just works.  It's built into git to interface with Mac's Keychain service.

Or else just install Git-Credential-Manager-for-Mac-and-Linux from Microsoft.  You'll need Homebrew, which is a great package manager for Macs for various development tools.  Then follow the instructions: it's super easy.

Windows

Super easy.  Just download and install the .exe for Git-Credential-Manager-for-Windows from Microsoft.

Linux

There's 3 possibilities:

use Git-Credential-Manager-for-Mac-and-Linux

You can install Git-Credential-Manager-for-Mac-and-Linux from Microsoft.  You'll need Linuxbrew, a package manager I've never heard of before today.  Then follow the instructions: it's looks easy.

But this is not my favorite option because:

1. never heard of Linuxbrew
   
   
2. MS Git-Credential-Manager sends telemetry to Microsoft.  Not much telemetry data, and I'm trusting of MS more or less, but if you're using Linux, I'm going to guess you might see "telemetry" and "MS" and wonder why it's needed for using Git.
   
   
3. someone's tried it a year ago and it didn't work

use Libsecret (best option)

It's 3 lines of commands to run:

sudo apt-get install libsecret-1-0 libsecret-1-dev
sudo make --directory=/usr/share/doc/git/contrib/credential/libsecret
git config --global credential.helper /usr/share/doc/git/contrib/credential/libsecret/git-credential-libsecret

This saves your credentials encrypted in ~/.local/share/keyrings.

Yes, you're downloading and compiling it yourself as it's not built-in... in 2020. Crazy.  But is apparently still The Way to go with Ubuntu or Lubuntu 19.10.

Libsecret should interact with the OS level password store.  On Ubuntu, that would be gnome-keyring.  If you need to manage the keys stored by gnome-keyring, you'll need to install another tool like the GUI utility Seahorse:

sudo apt-get install seahorse

use the built-in store (totally insecure and NOT encrypted)

Totally built-in.  Nothing to install.  One line to set up:

git config --global credential.helper store

It stores your passwords in PLAIN text in a file in your home directory.  Don't do this.  Anyone can read your password.  I can read your password.  So don't do this.

One way to use SemVer for software versioning

Everyone has their own system for versioning in their software development process.

Semantic Versioning is very popular of course.  It basically takes the form of:

major.minor.patch-prerelease+build

• Major for breaking changes.
• Minor for backwards compatible feature additions.
• Patch for bugfixes meant to be backwards compatible.
• Pre-release tags for internal versioning, building up to a release.
• Build for internal build numbers, useful if you build a lot.

There is a precedence order to SemVer numbers to essentially designate which version is "newer" in some sense.

Pre-release and Build tags do not participate in the precedence order.   So when specifying ranges of versions, those pre-release tags are kind of ignored in things like NPM contrary to precedence order as SemVer defines it --- reality is different than theory, right?

Pre-release tags are great for Designating development stages but when they are removed to do a non-pre-release release (e.g. a final release), it messes up the lexicographical ordering --- i.e. messes up the order in which they show up in my file browser. haha.

How I use SemVer

So I'm trying a SemVer compatible system that respects the 2nd and 3rd laws: "Don’t mess with math", and "Make friends with infinity.  In other words, don’t be afraid to increment".

The basic idea is: keep pre-releases to a patch level, release at the next patch level.

The rules are:

1. Start at 0.1.0.
2. Increment patch number to make a release
3. Increment major, minor, or patch (whichever you're targeting for next) to make pre-releases
4. Pre-releases are tagged a1, a2, ..., b1, b2, ..., rc1, rc2, etc.
5. Use increasing build numbers if you need
6. Use a "." then another build field if you must, like for adding a non-increasing alphanumeric build field (e.g. a SHA)

Example

So you'll get versions of WildApp like these, e.g.:

• WildApp 0.1.0-a1
• WildApp 0.1.0-a2
• WildApp 0.1.0-b1
• WildApp 0.1.0-b2
• WildApp 0.1.0-b3
• WildApp 0.1.0-rc1
• WildApp 0.1.0-rc2
• WildApp 0.1.1
• WildApp 1.0.0-a1
• WildApp 1.0.0-a2
• WildApp 1.0.0-b1
• WildApp 1.0.0-b2
• WildApp 1.0.0-b3
• WildApp 1.0.0-rc1
• WildApp 1.0.0-rc2
• WildApp 1.0.1

I'm going to give it a try at least.