> because I sync’d them to a usb stick with gitea

Just a tip: no need to use gitea if you want to replicate a git repository to somewhere else on disk/other disk.

Just do something like this:

    mkdir /media/run/usb-drive/my-backup-repo
    (cd /media/run/usb-drive/my-backup-repo && git init)
    git remote add backup /media/run/usb-drive/my-backup-repo
    git push backup master

And now you have a new repository at /media/run/usb-drive/my-backup-repo with a master branch :) It's just a normal git repository, that you also can push to over just the filesystem

Even better with

    cd /media/run/usb-drive/my-backup-repo && git init --bare

Bare repositories don't have a working directory. You can still git clone / git pull from them to get the contents. You can also git push to them without clobbering any "local changes" (there aren't any).

More detail here:

https://www.atlassian.com/git/tutorials/setting-up-a-reposit...

Yeah, better in terms of saving space, but I think it confuses some people, hence I didn't use it in my above example. Previous time I recommended a co-worker to use the `push to a directory` way of copying a git repository, I made them create a bare repository, and they ended up going into the directory to verify it worked and not seeing what they expected. Cue me having to explain the difference between a normal repository and a bare one. It also confused them into thinking that a bare repository isn't just another git repository but a "special" one you can sync to, while the normal one you couldn't.

So in the end, simple is simple :) Unless you're creating remote repositories at scale, you probably won't notice a difference in storage usage.

I hear all that, but --bare is necessary in this case because git (by default) won't let you push to a non-bare filesystem branch:

    ~/temp/a:master  $ git push backup
    Enumerating objects: 3, done.
    Counting objects: 100% (3/3), done.
    Writing objects: 100% (3/3), 212 bytes | 212.00 KiB/s, done.
    Total 3 (delta 0), reused 0 (delta 0), pack-reused 0
    remote: error: refusing to update checked out branch: refs/heads/master
    remote: error: By default, updating the current branch in a non-bare repository
    remote: is denied, because it will make the index and work tree inconsistent
    remote: with what you pushed, and will require 'git reset --hard' to match
    remote: the work tree to HEAD.
    ...
    To ../b
    ! [remote rejected] master -> master (branch is currently checked out)
    error: failed to push some refs to '../b'

  git clone --mirror
  git clone --bare
  git push --mirror
  git push --all

"Is `git push --mirror` sufficient for backing up my repository?" https://stackoverflow.com/questions/3333102/is-git-push-mirr... :

> So it's usually best to use --mirror for one time copies, and just use normal push (maybe with --all) for normal uses.

git push: https://git-scm.com/docs/git-push

git clone: https://git-scm.com/docs/git-clone

You can even take it a step further and have a push to origin update your backup as well.

https://stackoverflow.com/a/14290145

> In recent versions of Git you can add multiple pushurls for a given remote

Woah, that's really cool, didn't know about that. This is really useful! Thanks for sharing that.

Gitea has a cron task that pulls-in changes on an ongoing basis.

If a snapshot suffices, a once off "git push" or "git clone" works (but that's not too far off from downloading a tar ball, is it?). If you want to have a up-to-date local copies of multiple repos, a SQLite-backed Gitea instance is the simplest solution.

An added bonus to using Gitea is flexibility in mirroring LFS objects, which can be sent to S3 or minio

> a SQLite-backed Gitea instance is the simplest solution

Agree to disagree :)

This seems like the simplest solution:

    git remote set-url --add --push origin git@github.com:my-user/my-repo.git
    git remote set-url --add --push origin /backups/repos/my-user/my-repo.git

Now when you push to origin, it pushes to your local backup as well, everything up to date, no external sosftware at all :)

Thanks dabber for sharing this trick (https://news.ycombinator.com/item?id=34603174)

This does not include the cron jobs to pull in changes others make daily/weekly/every N hours. I mentioned that Gitea is superior under very specific conditions (where one wants to have latest version available locally).

I did not realise you could set the remote's URL to a local filesystem path.

That opens some interesting possibilities.

Cheers

Have you tried running gitea? It's very light on resources, has good documentation, and also defualts to a main branch. It's also very easy to control where all the data is stored, and works well w/ sqlite.

Is the "main" branch an advantage? I guess only if >50 percent of your repos use "main" branch

Yes, I've tried it (and actually run a personal instance myself), but I would never try to run an application meant as an webapp when I want to copy something from one filesystem to another, when git can do it already without any external programs.

Also, the `master` is just an example, it works for `main` as well, don't worry :) The created git repository on your usb-stick works like a regular git repository, you can use whatever branch names you want.

Btw, way to focus on the absolutely least interesting part of my comment, what I chose to name the branch...

The biggest reason to do this is thah it supports "mirror" repositories where it will keep your copy up to date, even using github keys to get at a private repo if you want.

Yes, and if you stop the process and start it again, gitea doesn't complain and picks up right up where it left off. Ditto if you lose internet connectivity. It's a well-designed piece of software. I considered using it as a BaaS and am actually thinking again of using it as one.

You can change the default default branch on GitHub via <https://github.com/settings/repositories>.

I believe new GitHub accounts now have that set to main.

The same works also over SSH using user@host:path for the remote - you don't need a deamon running on your server to push to it.

For this I have a NAS with a pretty basic script that runs nightly to clone any new repos I have and update those already backed up. They get organised into a directory structure mirroring that of Github: `./github.com/user/repo`

If of any use to anyone else: https://gist.github.com/wjdp/a20cb15f76b651124b3b27cde06d121...

> If the YouTube algorithm nukes your account and all your videos, you should be ready to upload them to a new account. Same with anything else digital.

Do you know if this is a common occurrence?

Also, I'm only a YouTube viewer and am not familiar with all the creator tools, problems, communities, etc. But would a creator really re-upload all their back-catalog if deleted? Just to try to get back to views and things?

I remember someone posting an agonized screed, some time ago, about YT deleting their channel, and all the videos.

Apparently, they had not kept the source/rendered originals of the videos, so it actually clobbered their business.

I am a scarred, limping old coot, and have learned [the hard way] that backups are goooood.

> I am a scarred, limping old coot

That is a delightfully evocative phrase

A few weeks ago, youtube changed their swearword policy. A creator I follow basically had to delete half their channel or risk termination.

They're not banning channels based on swearwords (yet, anyway). They are demonetizing videos with swearing - in the first bit, if too much, maybe other rules, but nobody is getting banned from saying 'shit'.

If you don't want monetization, is swearing in your videos to avoid your subscribers having to watch ads a viable strategy?

(To get around this: https://www.forbes.com/sites/johnkoetsier/2020/11/18/youtube...)

Huh, that probably explains... I was in a youtube rabbit hole right around then when some videos suddenly wouldn't load, turned out that I might've been the final viewer of the (small) channel that had had been banned at that moment. I was wondering what the chances were.

edit: Seems like it. The channel[1] name probably raised some new flag, and Google did its thing. Seems fair, it's not like a reasonable moderator would know of a concept of a second chance or anything.

[1] https://web.archive.org/web/20181123103308/https://www.youtu... https://web.archive.org/web/20220624154617/https://www.youtu...

// Ah, that channel was a pretty interesting part of the rabbithole of net culture-related parody too - rare to see collaboration like that

Battlestar Galactica did it right - https://www.youtube.com/watch?v=rrYdQnz8vJg

There were a whole bunch of artist and genre specific mixes I used to listen to on yt that are gone now. The uploaders accounts have all been nuked too. The sad thing is I can listen to it all on Spotify but it's not the same.. the creator's did not insignificant work to mix the songs together.

Maybe not on YouTube, but the gunTubers are having issues with YouTube changing their interpretation of the rules and instantly issuing 3 strikes against them for rule violations. And so, it'd be good to have a back catalog to upload to a different service to keep that older material available.

Wonder if any data hoarders have made scripts to clone every site you have started on GitHub?

I'm reasonably certain that if YouTube deletes your account uploading them to a new account is expressly forbidden.

I’ve read having a secondary test account to post videos under to pass YouTube scans before posting to the real account helps minimize issues.

How exactly can they stop you?

What do you mean? They have extensive content ID/checks.