5 ms·

> 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 di

> 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

benatkin 4y ago
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.
- tryauuum 4y ago
  Is the "main" branch an advantage? I guess only if >50 percent of your repos use "main" branch
  - benatkin 4y ago
    [flagged]
    - deleted 4y ago
      [deleted]
    - Alupis 4y ago
      That is an awful lot of contortions you are doing here, to seemingly justify a word change that has had well-cemented meaning within the tech community since it's inception. We all know why this change exists, and why some people will attempt to persuade others of it's superiority. It is, however, just silly virtue signaling, and it's exhausting to hear and read. It would require some very irrational and underdeveloped reasoning to assert this word has anything to do with oppression in 2023. There is no negative connotation, except in those who wish to perpetuate some weird sensation of altruism... ie. no one is safer or feels better simply because you choose to call it "main" rather than "master".
      - ceejayoz 4y ago
        > It is, however, just silly virtue signaling, and it's exhausting to hear and read. You should be aware that complaints about supposed virtue signaling are equally exhausting.
      - jrockway 4y ago
        I'm willing to go out of my way to use a different word if it makes people feel better (the root of the master -> main transition). But this is the rare case where it benefits me by having to type two less characters whenever I refer to the branch! main is truly a win/win.
        Alupis 4y ago
        > I'm willing to go out of my way to use a different word if it makes people feel better Which is just the thing, really. It makes no one feel better. It makes the privileged speaker feel better, with a false sense of virtue. It's a "look at how great I am" signal, nothing more. No one is harmed or made to feel bad by using the word master. Sometimes the adults have to be present in the room, it seems. Saving 2 characters is an equally silly excuse, but at least it has a realistic rationale. To that end, why stop at main - why not just 'm'? You can call it whatever you want in git.
        benatkin 4y ago
        It's because main is a goldilocks word for something like a default branch name. It isn't too long and isn't too short. It also isn't shorter in terms of syllables. Good design :)
        sshine 4y ago
        > main is a goldilocks word I totally agree. > Good design Having one default instead of two is better design.
        deleted 4y ago
        [deleted]
    - endgame 4y ago
      And it is _still_ causing completely avoidable pain, years after people started advocating for the change. A recent example I tripped over: https://github.com/brendanhay/amazonka/issues/815#issuecomment-1246132144 https://github.com/brendanhay/amazonka/issues/815#issuecomme...
- simcop2387 4y ago
  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.
  - benatkin 4y ago
    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.
- capableweb 4y ago
  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...
- neodon 4y ago
  You can change the default default branch on GitHub via <https://github.com/settings/repositories https://github.com/settings/repositories>. I believe new GitHub accounts now have that set to main.
dabber 4y ago
You can even take it a step further and have a push to origin update your backup as well. https://stackoverflow.com/a/14290145 https://stackoverflow.com/a/14290145
- capableweb 4y ago
  > 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.
josephg 4y ago
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-repository/git-init https://www.atlassian.com/git/tutorials/setting-up-a-reposit...
- capableweb 4y ago
  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.
  - josephg 4y ago
    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'
    - 4y ago
spartanatreyu 4y ago
I did not realise you could set the remote's URL to a local filesystem path. That opens some interesting possibilities. Cheers
sangnoir 4y ago
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
- capableweb 4y ago
  > 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 https://news.ycombinator.com/item?id=34603174)
  - sangnoir 4y ago
    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).
account42 4y ago
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.

benatkin 4y ago

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.

tryauuum 4y ago
Is the "main" branch an advantage? I guess only if >50 percent of your repos use "main" branch
- benatkin 4y ago
  [flagged]
  - deleted 4y ago
    [deleted]
  - Alupis 4y ago
    That is an awful lot of contortions you are doing here, to seemingly justify a word change that has had well-cemented meaning within the tech community since it's inception. We all know why this change exists, and why some people will attempt to persuade others of it's superiority. It is, however, just silly virtue signaling, and it's exhausting to hear and read. It would require some very irrational and underdeveloped reasoning to assert this word has anything to do with oppression in 2023. There is no negative connotation, except in those who wish to perpetuate some weird sensation of altruism... ie. no one is safer or feels better simply because you choose to call it "main" rather than "master".
    - ceejayoz 4y ago
      > It is, however, just silly virtue signaling, and it's exhausting to hear and read. You should be aware that complaints about supposed virtue signaling are equally exhausting.
    - jrockway 4y ago
      I'm willing to go out of my way to use a different word if it makes people feel better (the root of the master -> main transition). But this is the rare case where it benefits me by having to type two less characters whenever I refer to the branch! main is truly a win/win.
      - Alupis 4y ago
        > I'm willing to go out of my way to use a different word if it makes people feel better Which is just the thing, really. It makes no one feel better. It makes the privileged speaker feel better, with a false sense of virtue. It's a "look at how great I am" signal, nothing more. No one is harmed or made to feel bad by using the word master. Sometimes the adults have to be present in the room, it seems. Saving 2 characters is an equally silly excuse, but at least it has a realistic rationale. To that end, why stop at main - why not just 'm'? You can call it whatever you want in git.
        benatkin 4y ago
        It's because main is a goldilocks word for something like a default branch name. It isn't too long and isn't too short. It also isn't shorter in terms of syllables. Good design :)
        sshine 4y ago
        > main is a goldilocks word I totally agree. > Good design Having one default instead of two is better design.
        deleted 4y ago
        [deleted]
  - endgame 4y ago
    And it is _still_ causing completely avoidable pain, years after people started advocating for the change. A recent example I tripped over: https://github.com/brendanhay/amazonka/issues/815#issuecomment-1246132144 https://github.com/brendanhay/amazonka/issues/815#issuecomme...
simcop2387 4y ago
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.
- benatkin 4y ago
  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.
capableweb 4y ago
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...
neodon 4y ago
You can change the default default branch on GitHub via <https://github.com/settings/repositories https://github.com/settings/repositories>. I believe new GitHub accounts now have that set to main.

dabber 4y ago

You can even take it a step further and have a push to origin update your backup as well. https://stackoverflow.com/a/14290145 https://stackoverflow.com/a/14290145

capableweb 4y ago
> 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.

josephg 4y ago

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-repository/git-init https://www.atlassian.com/git/tutorials/setting-up-a-reposit...

capableweb 4y ago
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.
- josephg 4y ago
  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'
  - 4y ago

spartanatreyu 4y ago

I did not realise you could set the remote's URL to a local filesystem path. That opens some interesting possibilities. Cheers

sangnoir 4y ago

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

capableweb 4y ago
> 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 https://news.ycombinator.com/item?id=34603174)
- sangnoir 4y ago
  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).

account42 4y ago

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.