Re: rsync busy non-bare git repo 'source' to quiet

[Neal Kreitzinger <nkreitzinger@gmail.com>]

On 3/8/2011 4:38 PM, Jeff King wrote:
> On Tue, Mar 08, 2011 at 04:20:33PM -0600, Neal Kreitzinger wrote:
>
>> Rsync seems like a simpler solution and more accurate solution for
>> creating a copy of an ecosystem of interrelated git repos colocated on
>> the same box.
>
> Sure. It is simpler, but not atomic unless you do a multi-stage rsync.
>
>> A previous post in the newsgroup states:
>>> If you want your rsync backup to be fine, you need to follow some
>>> ordering.  You need to copy the refs first (.git/packed-refs and
>>> .git/refs/), then the loose objects (.git/objects/??/*), and then all
>>> the rest.  If files are copied in a different order while some write
>>> operations are performed on the source repository then you may end up
>>> with an incoherent repository."
>>
>> Would that work?
>
> If you do it in that order, the end result will be a consistent repo.
> But during the copy, the refs at the destination will point to objects
> you don't have. I don't know if that matters for your case.
>
We won't be trying to used the "destination" repos during the rsync. 
The workflow will be:
(1) I need to test a change to the goldbox change control menu system.
(2) I determine that my testbox "copy" of the change control menu system 
has repos that are too out-of-date for a good test, so I run rsync to 
make a fresh copy of the goldbox.
(3) After the rsync is finished, I pull over just the branch that 
contains my untested change menu scripts.  (this is the only git pull i 
do from goldbox to testbox.)
(4) I test the changes and see they are good.
(5) I merge the changes into the master branch of the change control 
menu non-bare repo on the goldbox.  The menu runs from the working tree 
so now they are live.

Since I won't be trying to access refs in the "destination" repos via 
git commandline or gui while the rsync is running, it sounds like it 
will be ok.  I can keep people from banging on the testbox.  I can't 
keep them from banging on the goldbox.

In regards to the working tree of a busy "source" repo, it sounds like 
it could end up not matching the index.  At the end of the script I 
could execute a "git reset --hard && git clean -f" on each non-bare repo 
as you suggested.  That would be pretty straightforward.

Thanks!

v/r,
Neal