You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
So as @josegonzalez mentioned, all of the branches are in fact backed up and completely accessible if the remote repo goes away or if you don't have internet access.
You can easily view them using git branch -a and then check out and track any remote branch you want using git checkout --track origin/branch_name. Again, this works even if the remote gets deleted or if you have no internet access, as all of the remote branches are actually there locally, they're just not tracked.
@riophae the problem with that trick, is that while it works the first time, if you try to update the repo later using git fetch to continue backing up new changes, it will fail because it's no longer a bare repo.
For example (the extra flags are not causing the problem, a simple git fetch will fail with the same error, I'm just using the exact command here that the script does to update backups)
linux-mint-vm :: ~/Desktop/branch-test ‹git master› » git fetch --all --force --tags --prune
Fetching origin
fatal: Refusing to fetch into current branch refs/heads/master of non-bare repository
error: Could not fetch origin
So while it seems nice in theory, it seems like would only work for a one time backup...
However, I just tried setting core.bare to true again after the first clone before fetching using git config --local --bool core.bare true. That allowed the fetch to work and then when I pushed a new branch on another machine and used the same git fetch --all --force --tags --prune command again, not only did it sync the new branch but it tracked it and everything. So there may actually be a way to make this work!
Interestingly, when I tested doing a normal clone first then doing the rest of the steps in that link and setting core.bare to true again, it didn't track any of the new branches. It seems to only work if you first perform steps as described in that link, which is strange...
This seems very hacky though and potentially prone to breaking in the future as it's not clear if this is intended behavior or just unintentional behavior by the git client, so not sure it's worth implementing at the risk of breaking future backups, especially since as mentioned all of the branch data is in fact being backed up already.
I'll look into this some more later and do some more testing to better understand why that trick works in the first place. If I can determine that it's safe to implement, I'll try and change the script logic to do that so that all branches are automatically tracked.
Activity
zzc-tongji commentedon May 10, 2019
Is there any way to back up ALL things of the git repo? Just like "copy" from GitHub.
josegonzalez commentedon May 10, 2019
It clones the whole repo, so all commits are there, you just need to checkout the branch you want.
riophae commentedon Aug 2, 2019
Hi, how about using this trick to clone with all the branches?
https://gist.github.com/fernandoaleman/853916e1903b475820f5416bfe048cb8
In this way, the final result seems less confusing to me.
einsteinx2 commentedon Jan 7, 2020
So as @josegonzalez mentioned, all of the branches are in fact backed up and completely accessible if the remote repo goes away or if you don't have internet access.
You can easily view them using
git branch -aand then check out and track any remote branch you want usinggit checkout --track origin/branch_name. Again, this works even if the remote gets deleted or if you have no internet access, as all of the remote branches are actually there locally, they're just not tracked.@riophae the problem with that trick, is that while it works the first time, if you try to update the repo later using
git fetchto continue backing up new changes, it will fail because it's no longer a bare repo.For example (the extra flags are not causing the problem, a simple
git fetchwill fail with the same error, I'm just using the exact command here that the script does to update backups)So while it seems nice in theory, it seems like would only work for a one time backup...
However, I just tried setting
core.bareto true again after the first clone before fetching usinggit config --local --bool core.bare true. That allowed the fetch to work and then when I pushed a new branch on another machine and used the samegit fetch --all --force --tags --prunecommand again, not only did it sync the new branch but it tracked it and everything. So there may actually be a way to make this work!Interestingly, when I tested doing a normal clone first then doing the rest of the steps in that link and setting
core.bareto true again, it didn't track any of the new branches. It seems to only work if you first perform steps as described in that link, which is strange...This seems very hacky though and potentially prone to breaking in the future as it's not clear if this is intended behavior or just unintentional behavior by the git client, so not sure it's worth implementing at the risk of breaking future backups, especially since as mentioned all of the branch data is in fact being backed up already.
I'll look into this some more later and do some more testing to better understand why that trick works in the first place. If I can determine that it's safe to implement, I'll try and change the script logic to do that so that all branches are automatically tracked.
Iamrodos commentedon Dec 3, 2025
@josegonzalez this can be closed as it was addressed by #457