Backing up via GitHub repo

sdetweil

@arnedebeer well, then, didn’t used to be… I see its changed… thanks…

arnedebeer

@sdetweil perhaps your four layer backup routine isn’t needed after all!:winking_face:

bhepler

In all honesty I don’t think it’s necessary to back up your entire Magic Mirror. If you back up the config.js file, you can rebuild your mirror pretty quickly. It will contain all of your API keys and a list of the modules you have installed. The hard part will be locating the Github repos to clone the repositories.

And you did star all of the module repositories you need, right? That would put them all on a very convenient web page.

sdetweil

@arnedebeer well, there is a LOT of stuff on this machine… lots more than MM…

arnedebeer

@bhepler I think you’re quite right to be honest. But by forking the entire project this won’t be possible, that’s why I was hoping it was possible to create a repo for it to automate the backup.

Perhaps a better way to back my config up is to create a script that mails the config every x amount of time to myself :thinking_face: :thinking_face:

bhepler

@arnedebeer - If you must. I make it a practice that I back up the config.js just before I modify it. That way I don’t have a dozen identical copies of the file sitting around. It also lets me easily see when was the last time I changed the mirror.

BitVise is good for this, as it will open a terminal window and an SCP window, which serves as a good reminder to copy the config file down before I do anything.

karsten13

you can do that with a git repo which is located above your MagicMirror git repo.

If you have a path structure e.g. ~/mm/MagicMirror where MagicMirror contains the MagicMirror-git-repo goto ~/mm and create a new git repo there with git init. Create a .gitignore file in ~/mm and put the line MagicMirror in it so this subdir is ignored.

Now you can add files or directories with

git add -f MagicMirror/config/config.js
git add -f MagicMirror/modules/*

Then commit.

sojourner

The MM repo has a git configuration to only track the “default” folder in the MM/modules folder. This is cool because you can have a separate git repository inside another! When you like a module someone (even yourself) created on github, you need to install it in the MM/modules folder. For example, from the MagicMirror/modules directory, I’m cloning a repo:

[MagicMirror/modules]> git clone https://github.com/sdetweil/MyCovid19.git

You’ll see that a new directory is created under the “modules” directory – and it’s the same name as the git repository. Important to this discussion; the MagicMirror repo doesn’t care about this new directory! You follow the usual steps to update MM with no git side-effects … and … you can update the new module directory that you cloned using the same “git pull” process!

Side note: there are often a few more steps needed to install a module. In this example, @sdetweil follows best practice to include installation instructions in the module README.

So, in a general case, you can create a repo, for example, “MyStuff” in the MM/modules folder. It can contain anything and you can manage it (edit files/push/pull/branch/etc.) all within the “MM/modules/MyStuff” directory.

Just don’t call your repository “default”! :-b

fyi - Git keeps track of files/directories to ignore within a repository by using a .gitignore file located in the repo’s root folder. Check out all the files the MagicMirror ignores!

sojourner

@karsten13 Git supports nested repositories. No need to create a higher level repo and then ignore the MagicMirror. There’s already a line in the MagicMirror/.gitignore

# Ignore all modules except the default modules.
/modules/**

So anything can be created in the MagicMirror/modules directory – and it is ignored by the MM repo.

karsten13

My answer is related toI was wondering how I could backup my config and modules folder to a private repository on GitHub.

So if you want to put config and modules in one git repo without the other MagicMirror stuff, if found no other solution as doing it with such a “parent” construction as described …