I’m working on converting two large svn repos to git. Both have large binary files stored in them so I’m using git lfs to make them more manageable. However the repos are large enough that the normal tools don’t work so I’m using the BFG repo cleaner to do the lfs migration. And this, plus the subgit migration tool leave loads of .gitattributes files laying around. They’re easy to remove, but I need .gitattributes files in there for lfs to function correctly.

One issue with infrastructure sorts of repositories is what to do with sensitive data. Keys, tokens and other secrets shouldn’t be committed to git repos, but they have to go somewhere. In some cases you can put them in your CI/CD system and import them as variables. But that gets complicated quickly. One way to address it is to use git crypt. It’s not a standard git extension, but it’s been around for a fair bit of time.

I’ve written a few articles on using vcsh for tracking your home dir. Unlike previous options vcsh lets me use multiple repositories. My first experiment with this was a past repository. Lots of Unix tools use the GNU readline library so there are a number of history files to collect. I already was collecting all of them in ~/.history.d. In addition due to problems with NFS mounted home dirs I’d long ago put the hostname in the names of history files as a way to prevent file corruption.

People don’t think of the unix command line as a UI, but it is and it has its own idioms. Nearly all of them are conventions, not hard and fast rules. Because of this sometimes things take on a few meanings. The first meaning of the dash, "-" is to mark a command line flag like ls -l or mkdir -p. It comes up less often, but another pretty well known meaning is stdout/stdin.

Yesterday I covered the overview of how this gets deployed. Now for the detail. The script for testing is more aspirational than functional. It runs a spellcheck on the blog, but doesn’t die if it finds any. I’m supposed to read the output. I never do. I should though. Someday I’ll add consequences to the spellcheck run, but for now at least it tries. #!/bin/sh set -e make spell Next up is the script that does the build and deployment to pages.

This website is maintained with hugo which is a static site generator. That means the source is parsed and all of the html, css and javascript are generated and saved as files. It means deployment just requires a plain, basic web server. But that still does mean it needs to be deployed. You could deploy just on s3 but for me I already have my own server. So I just deploy it to there.

A while back I switched to vcsh. I’ve written a few articles on using it but since then I’ve migrated machines a number of times. The big issue I’ve found is having to manually install software on each machine. There are things my scripts depend on and things I just expect to have and manually creating them each time is annoying. So the solution obviously is a script. It’s actually used all the time as I might create new dependencies or find new tools I need so I’d want that installed on all machines.

tl;dr my year in vim Gource is a neat tool for visualising the history of a of a software project. In a way it’s kind of a fun combination of this scene Jurassic Park and version control. Reading up on it I learned it could also visualise multiple repositories so I decided it would be kind of fun to do just that. I use vcsh to manage my home directory, pass to manage passwords, Hugo for my website and slack for managing my personal servers.

For a number of projects I work on I pull in third party tools. Sometimes they’re straight copies - that’s what I inherited in some PHP projects I work on. But in others I use git subtree to pull them in. However there’s a problem. I need a way to remind myself to check for updates. And generally I like things related to a project to live in the project. For my home projects I use Gitlab and their CI system.

The Heartbleed OpenSSL bug has been in the news a lot. And like many security stories there have been a few conspiracy theories floating around. Since OpenSSL is open source software, anyone can view the hostory of the project and see how the bug came about. But it does require understanding some tools. In this post I hope to help explain them. Step 1: Find The OpenSSL Source. A good way to do this is to search for the project name and git or svn or hg.