Back in the time, this blog was hosted on and by GitHub Pages, now Microsoft’s (as NPM more recently).
But today, we won’t be talking about the whole “embrace, extend, and extinguish” capitalist strategy, but rather Git.
You know Git, this little piece of software firstly written in two days and today daily used on Earth.
We are always looking for the next cool-but-functional graphic (including Web) interface to embellish and represent projects sources, but it’s
always often about the same program underly.
([Microsoft’s] GitHub’s) Pages is cool and handy, and I actually decided to keep Jekyll as the static HTML generator engine for my blog.
Self-hosting allows you to really appreciate some technical constraints, the same constraints often hidden when services are operated by large
Basically, let’s take this very blog as an example.
I have been, and for some years now, pushing non-diff-able objects (as images or minified front-end assets) to the Git tree.
It might be deadly-stupid
(and stored by GitHub when using Pages), but that’s not viable on the long run.
Here comes the main subject of this post : Git LFS.
Git LFS is a project allowing developers to version files that couldn’t be version-ed by Git alone (those I qualified “non-diff-able” above).
By using short and diff-able pointers in the Git history, we might (finally) store binaries (or equivalent) without duplicating repositories size each time we update them.
And you know what ? It’s packaged in Debian Buster (and back-ported to Stretch ), so :
Git LFS is well-supported by popular code hosting services, see some examples below :
GitHub, since 2015 ;
GitLab, since v8.2 (2015 too) ;
Gitea, since v1.1.0 (2016).
As every other existing things on this planet, it comes with its own limitations, and before diving in, I’d advise you to consult them to check whether you are concerned or not.
Migrate Existing Repositories
Yeah, LFS is pretty cool and you should think about it before creating a new project and/or pushing non-diff-able data to a remote (and often, collaborative) repository.
But what about existing projects ?
How am I supposed to do if I want to keep the whole Git history AND migrate existing “binaries” to LFS ?
An awesome project comes with an awesome team : they thought about it.
Below is a very simple procedure to migrate already-referenced-contents.
Please adapt it, ‘cause you know, YMMV :
Wow, you’re done too ! Congratulations.
Your next (optional, but recommended) steps :
Run the garbage collector (if possible) on the remote (see example below on the Gitea administration dashboard) ;
Tell your colleagues to install Git LFS too BEFORE properly re-cloning the affected repository ;
Apply the same previous operation on “read-only” mirrors (as your production for instance) ;
Re-enable your CI/CD hooks.
TL;DR No, I have not been hacked, I have voluntarily recently rewritten the whole blog Git history.