-1

I have seen some suggestions to backup git remote repository by git clone --mirror, I found another way to make a copy of remote repository directly, when the git remote repository broken, rename the copy, from some basic tests, this way looks good, does it have any side affect?

jonrsharpe
  • 115,751
  • 26
  • 228
  • 437
vakano
  • 31
  • 2
  • 1
    I don't know how you are hosting your remote Git stuff, but I'm fairly certain that the big providers such as GitHub and Bitbucket backup their own data already. If you're using one of them, you might not need to worry about this. – Tim Biegeleisen May 16 '17 at 14:26
  • 2
    [Previous SO answer](http://stackoverflow.com/questions/5578270/fully-backup-a-git-repo) – Seth May 16 '17 at 14:27
  • 1
    @Seth - Except the question here is about the possible side effects of one way of backing up, not a request for additional ways to do a backup – Mark Adelsberger May 16 '17 at 14:32
  • Possible duplicate of [Fully backup a git repo?](http://stackoverflow.com/questions/5578270/fully-backup-a-git-repo) – PatrickSteele May 16 '17 at 16:53
  • Not a good dup; the other question asks for ways to back up, this question asks about the differences between two known ways of backing up – Mark Adelsberger May 16 '17 at 17:42

1 Answers1

1

Does it have side effects? Probably. Do they matter? Probably not.

One nice thing about using a mirror clone operation to back up the repo is that you can do it from another server. Copying the repo to another directory, if that other directory is local to the original, is next to useless. (It will help you if the repo becomes corrupted due to a bug in a git operation - which I've never seen; or if a git operations deletes information in an unrecoverable way - which is not so easy to make happen. But more common failure modes, like a server being struck by a meteor, require off-site backups. And yes, rare as it is, I consider "server hit by meteor" to be a more common risk than git corrupting the repo...)

But maybe you're copying to a network share; certainly an fs-level copy of the repo also can be used for an off-site backup. So what fundamentally is different between the two approaches?

Cloning does not copy reflogs. That also means it may not properly capture stashes[*] (but why would you have stashes on origin?). If there are local changes on the repo, they (the index and work trees) won't be captured by a clone. (But then, you generally wouldn't have local changes on the origin repo...) Cloning may not copy unreachable objects. Cloning may pack loose objects as it copies them.

(Note the "may do this, may do that"; it depends how you clone. A remote clone should pack objects and can reasonably be expected to omit unreachable objects.)

So a clone may produce a smaller / more efficient backup image, but an fs-level copy is technically a higher-fidelity backup. That said, the things that you'd lose by cloning probably aren't important in an origin repo.

[*]to clarify, the stash ref should be copied by a mirror clone, which would make the most recent stash reachable; but if there are multiple stashes, the "stash stack" is maintained in the reflogs

Mark Adelsberger
  • 42,148
  • 4
  • 35
  • 52