Re: mirror git repos: rsync vs. --mirror

From: Julian Phillips <julian@quantumfyre.co.uk>
Date: Mar 30, 2010, 22:00 UTC
Message-ID: <3a75d1efc7cf125d84b8e02b7dabf7aa@212.159.54.234>
In-Reply-To: <robbat2-20100330T205331-531407911Z@orbis-terrarum.net>

On Tue, 30 Mar 2010 20:54:09 +0000, "Robin H. Johnson" <robbat2@gentoo.org> wrote:

Show 5 quoted lines

> I'm trying to see about the state of automated mirroring git
> repositories between different systems, eg. a private backend and a
> public frontend, and ran into a catch between two possible options, each
> with a downside. If there are other means besides these, I'm all ears
> for them.

You can mitigate the git caveats somewhat ...

Show 16 quoted lines

> git clone --mirror && git fetch:
> --------------------------------
> How:
> - Setup with: "git clone --mirror URL"
> - Cronjob with: "git fetch"
> Benefits:
> - Extremely fast
> - Light on traffic
> Caveats:
> - Branches and tags deleted in master persist in slaves :-(
> - Seperate gc/repack needed on slaves.
> 
> The traffic vs. deleted branches/tags is the main tradeoff here, esp. as
> repos get larger.
> 
> Can git-fetch perhaps be made to delete the branches/tags?

I don't think that fetch can do it, but "git remote prune origin" will. You could also add "git gc --auto" to your cron script to deal with the repacking - I don't think fetch already does that ...

-- 
Julian