@sdetweil resolved in less than 24 hours :-) This is “responsive” !
Thanks again!
Ralf

@sdetweil OK; cool! Thanks again for all your effort!

Warmest regards,
Ralf

Dear Sam, @sdetweil ,

sorry for the late reply — time zones 😊 (it was night here in Germany when you posted).

To answer your question: the right branch is main.
That’s where mm_backup.sh pushes to
(git push -f origin main) , and that’s where backups should live.

The problem is that mm_restore.sh creates and checks out a “restore”-branch but never switches back (to main) or deletes “restore” afterwards. So after a restore, the local repo stays on restore-branch.

When mm_backup.sh runs next, it does git add and git commit — which goes to the currently checked-out branch (restore-branch), but then pushes main. So the new backup commit is “lost” on the wrong branch.

I think the simplest fix would be to add a git checkout main at the beginning of mm_backup.sh,
before any git operations. That way it always commits to the right branch regardless of what
happened before.

Alternatively, mm_restore.sh could clean up after itself by switching back to main and deleting
restore-branch when it’s done.

Thanks for looking into it!

Warmest regards,
Ralf

Dear Sam ( @sdetweil) ,

Hope you’re doing well! I’ve been using your MagicMirror backup-restore scripts for quite a while
now and they’ve been super helpful - thank you so much for maintaining them!

I just ran into a small issue that I wanted to share. At some point in the past, I had used
mm_restore.sh, which left my local backup repo on a branch called restore-branch. When I ran
mm_backup.sh today (after a loooong time) , it committed the backup to restore-branch (since that was
the checked-out branch), but the push command on line 511 explicitly pushes main:

git push -u origin main refs/tags/$next_tagnumber

So the tag got pushed correctly, but the actual backup commit never made it to main on GitHub -
because the commit was on restore-branch while the push targeted main (which still pointed to the
old commit).

Easy fix on my end - I just merged restore-branch into main and pushed. But you might want to add
a git checkout main (or git switch main) somewhere before the commit step in mm_backup.sh, so the
script always commits to the right branch regardless of which branch happens to be checked out.

Thanks again for all your work on this - and for all the help you are performing here for us!

Ralf

@wuermchen which fork are you using?
There was a newer implementation, I guess last year.
This version resolved the sticky caller-window (at least for me).

Good luck,
Regards,
Ralf

@pat59 You may should remove your credentials from the urls ….

Regards,
Ralf

@sdetweil
OK; thanks for this hint.
May npm install has avoided the resulting error which I had to solve…

Anyway: Thanks a LOT!
Regards,
Ralf

@sdetweil
Yes :-)

In fact I’ve used

npm ci --omit=dev

this does the deletion of the node_modules folder inherently AFAIK …

Thanks again, dear Sam!

Ralf

@sdetweil
For some really strange reasons, neither

pi@MagicMirrorPi5:~/MagicMirror/modules/MMM-Remote-Control $ git fetch --all --tags
pi@MagicMirrorPi5:~/MagicMirror/modules/MMM-Remote-Control $ git fetch --tags

currently give any feedback…

So I’ve worked with the found git-hash:

git checkout 1f451ce

This at least worked and rolled back to V. 3.3.2.

Unfortunately some dependencies (package-lock.json ???) are not strict enough, so the rollback produces an error message:

[ERROR] Error when loading MMM-Remote-Control: require() of ES Module /home/pi/MagicMirror/modules/MMM-Remote-Control/node_modules/uuid/dist-node/index.js from /home/pi/MagicMirror/modules/MMM-Remote-Control/API/api.js not supported.

So I downgraded UUID:

cd ~/MagicMirror/modules/MMM-Remote-Control
npm install uuid@9.0.1
npm ci --omit=dev

With this module is running again.

From now on I’m in a in ‘detached HEAD’ state - but this seems OK.
Thanks for your time, effort and always great help!

Ralf

@sdetweil I’ve found V3.3.2 and just try "git checkout 1f451ce "