I've seen lots of people say you can backup git repositories by just copying them, but what happens if you are copying the repository at the same time that someone is pushing some changes up to it?
+2
A:
If you're worried about concurrency, it should be quite safe to instead use
git clone /my/repository/location /my/backup/location
As every git repository has a complete copy of everything, it's an effective backup which is guaranteed (at least as much as git itself is!) to be concurrency-safe
Steven Schlansker
2009-09-28 21:49:40
Note that this won't necessarily get the .git/config stuff, but that is mostly reproducible anyway. If you really want it, you can just do a straight file copy on it...
Steven Schlansker
2009-09-28 21:53:23
+1
A:
No, git's central data store is atomic, by design.
You cannot lose commits in this way, just refs.
If you lose refs they are easy to recover.
Alex Brown
2009-09-28 21:53:40
+3
A:
Basically what will happen is that you will get the complete repo at the time of copy. If there is a partial transaction hanging around from a push at time of copy it will be cleaned up as a failed transaction, just like you had lost a network connection while pushing to a remote repository.
stonemetal
2009-09-28 21:57:25
For backups, a nicer way of doing it is to push all branches to somewhere instead of doing a standard copy. I do this to backup my work to a flashstick:git remote add flashstick /media/flashstick;git push flashstick master
MichaelM
2009-09-29 00:13:45
A:
There might be a problem if copying takes long time, and if you somehow first copy object database, and then refs, while somebody is updating refs (that is why rsync:// transport is deprecated). I think if you copy refs first and then object database (and the rest) you shouldn't have any problems.
Jakub Narębski
2009-09-29 00:09:24