Skip to content

Releases: arcticicestudio/igloo

0.1.0

05 Apr 19:00
v0.1.0
Compare
Choose a tag to compare

Release Date: 2020-04-05 Project Board Milestone

Historical Background

Back on January 7 2017, this repository was created in order to open source my dotfiles that were stored and managed in a private repository on my server back then. The intention was to allow other to learn and use these files or even contribute back even though most of the time preferences and configurations are shaped for personal use. I also liked the great idea of the [“GitHub does dotfiles“][gh-dotfiles] project and the fact that a public repository makes it way easier for me to setup and bootstrap a new system without the requirement to configure and connect to my VPN before being able to clone and use my dotfiles.

Since then this repository changed a lot regarding the structure and data, forming my “digital source-of-truth“ for my systems. The main targets hosts were illuvigaq (later on [renamed to igloo][gh-10]) and archbook where the later was [replaced with iceowl][gh-143] later on by switching from Arch Linux running on a MacBook Pro 11,2 (2016) to [macOS on a new MacBook Pro 15,2 (2018)][gh-131].
Even though updates are documented and merged through an organized workflow, the repository was more like a constantly changing and moving kind of cache to keep the dotfiles reasonably maintainable and in sync between the systems.

The goal was to use the files in daily business, improve up on these usage experiences and finally persist the configurations into this repository. This is the way this repository was used for almost over 3 years and it worked reasonably well, but there are plans for a refactoring of the structure and workflow. In order to clarify this goal release version 0.1.0 is going to set a imaginary marker line in the repository history to persist and document the current repository state.

The following sections provide detailed documentations about all the snowblocks, snowflakes and everything else that has been done to build up the current dotfile state.

Repository Structure

Bootstrap script#1 (⊶ b516e30)

↠ Implemented the bootstrap shell script to run [snowsaw][] with the following configurations:

  • SNOWSAW_DIR=.snowsaw — Path to the snowsaw submodule.
  • SNOWSAW_BIN=.bin/snowsaw — Path to the snowsaw binary.
  • SNOWBLOCKS_BASE_DIR_NAME=snowblocks — Name of the base snowblock directory.
  • SNOWBLOCKSDIR=. — Relative path of the current working directory the bootstrap script runs in.

The actual execution command "${SNOWSAW_DIR}/${SNOWSAW_BIN}" -s "${SNOWBLOCKSDIR}" allows to add additional options by passing parameters through via "${@}".

MIT license migration#59#60 (⊶ 11c003e)

↠ Before the project code was licensed under the [Apache 2.0][apache-license] license. This often causes problems when developers want to use the project or code parts of it in another project licensed under a less restricted license.
The project migrated to the [MIT license][choosealicense-mit] which is more open, unrestricted and the most used license for open source projects like [React][] which has also recently been [re-licensed][fb-code-blog-react_relicense].

Updated copyright comment header#123 (⊶ 2e4d694)

↠ Before some files still used a “hard-coded“ copyright year that has now been changed to use the <YEAR_OF_BIRTH>-present pattern in order to prevent unnecessary overhead on each year change.
Also the copyright email for „Sven Greb“ was invalid and has been updated to the valid address.

Snowblocks

Git — #2 (⊶ fd43bda)

↠ Initially snwoblocks/git for [Git][] provided the following files & directories linked to their destination:

  • gitconfig~/.git-commit-msg
  • gitignore~/.gitignore
  • gitconfig_auth~/.gitconfig_auth (initially not tracked by Git but only created and linked locally)
  • git-commit-msg~/.git-commit-msg

Over the time the git snowblock evolved through the following changes:

  1. Conditional configuration inclusion #23#27 (⊶ 427e6cb)
    ↠ The new [conditional configuration includes][git-docs-config#incl] Git feature was introduced in version [2.13][gh-blog-git-2.13] provides a comfortable way to automatically load different configurations based on the current path of the repository.
    Many path specific projects have been added to to allow to split the main- and job authentication configurations.
    Also see the following related changes:

    • Conditional configuration includes for "gitlab" and "incubator" #97#101 (⊶ eca0252)
      ↠ Added [conditional configuration includes][gh-blog-git-2.13#cond_incl] for the gitlab and incubator directories using the default main Git configuration.
    • New conditional authentication configuration include #120 (⊶ 3697004)
      ↠ Ensured all communikey projects are configured to use the svengreb Git user a new conditional include for the ~/code/github/repositories/communicode/ path(s).
    • New conditional authentication config include #171 (⊶ 631ab5f)
      ↠ Ensured all projects by [@svengreb][gh-user-svengreb] are committed with the correct Git credentials a new conditional include for the ~/yggdrasil/svengreb/ path has been added.
  2. Simplified branch printing aliases #25#28 (⊶ 427e6cb)
    ↠ The branch printing aliases b and the extended aliases bum and bm have been simplified by removing unnecessary flags:

    • The --list flag is used to list branches matching a specific pattern.
    • Removed -v/-vv/--verbose which shows the commit SHA1 and subject line after each branch.
  3. Improved logging alias formats #24#29 (⊶ a316d77)
    ↠ The defined ASCII colors codes for the output have been changed to adapt to the terminal colors theme/scheme.
    The format has also been simplified and minimized/reduced to relevant information except the extended ll and llf aliases.
    Added the new shorthand aliases lf and llf were added for a flattened output without topic commits from merges and adapted the style to the existing lnew and lch aliases. The lr alias is now superfluous and has been removed due to the new ll and llf aliases which include the relative date of a commit.

  4. Long GPG keyid format for Git configuration #50#54 (⊶ a4065f5)
    ↠ The GPG [keyid-format][gpg-docs-conf_opts] has been changed from short to long.

  5. Adapted Git commit message template to style guide #51#55 (⊶ 272d1bf)
    ↠ The Git commit message template content was outdated and has been updated to adapt to the new [Git Style Guide][arcticicestudio/styleguide-git].

  6. Transparent Git encryption using GPG #64#69 (⊶ 32c24ce)
    Replaced by #113#114 later on!
    ↠ Added a global .gitattributes file and configured the global .gitconfig file to apply a transparent git encryption with smudge and clean filters using [GPG].
    In the .gitattributes file, a filter for all *.igloocrypt file extensions was set. The .gitconfig now includes the filter configuration by using gpg for the encryption and decryption, processing files just before they‘re checked out and just before they’re staged. Also see GitHub Gist [“Transparent Git encryption with smudge & clean filters using GPG“][gist-git_smudge_clean] for more details.


    6.1 Migration to git-crypt #113#114 (⊶ 4bb0d48)
    ↠ In #64 the concept was described as a simpler and cleaner solution instead of adding a using a tool like [git-crypt][] with the reason that this would make the encryption usage dependent on an external tool and also commits additional files to the repository like the .git-crypt folder in the root of the repository. It was also documented that such tools are really useful and necessary when the repository is used by many collaborator, but only adds overhead for personal dotfile repositories.
    Anyway, the transparent Git encryption introduced to [GPG] encrypt specific files using the smudge and clean filters only worked reasonably well with various problems, e.g. caused files to be flagged as „dirty“ (modified) after checkout even if there have been no changes. The pure Git builtin solution with filters was chosen to prevent dependence to external tools, but the latest release versions of Git causing more and more problems due to changes in the behavior e.g. [how git diff works][git-docs-diff] (also causing diff-so-fancy to be broken).
    Therefore the previously implemented solution has been removed again and, against contrary to the opinion in #64, migrated to use [git-crypt][] instead. Even if this added additional files to the repository as well as the external dependency to the tool itself, git-crypt is a stable and production proven concept that works safely and allows to really use a transparent encryption.
    After playing around and testing git-crypt locally the resulting migration steps were as follows:

Read more