On Fri, 17 Aug 2012 13:20:17 +0100
Adam Prescott <a...@aprescott.com> wrote:

> > In my shop, we back up each Git repo on the main server to its
> > mirror bare repository on another box using a call to `git fetch`:
> >
> > git fetch --quiet --prune <repo> '+refs/*:refs/*'
> >
> > which essentially means "bring everything the remote has, update
> > matching local things (overwrite, if necessary), then delete
> > everything the remote does not have anymore".
> 
> Aren't you just recreating `git clone --mirror`? If I remember, it
> will automatically prune any deleted refs on the next fetch.
Quite probably.  The problem with `git clone` is that it's supposed to
create a repository, but we keep the mirror repositories around
(I mean, they are not tarred and gzipped, and just sit there waiting
for the next backup round or for being used for disaster recovery).

The upside of this approach is that it minimizes transfers because they
become differential, and this allows to backup often, without worrying
too much about load spikes on the server and the network.

-- 
You received this message because you are subscribed to the Google Groups "Git 
for human beings" group.
To post to this group, send email to git-users@googlegroups.com.
To unsubscribe from this group, send email to 
git-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/git-users?hl=en.

Reply via email to