top button
Flag Notify
    Connect to us
      Site Registration

Site Registration

Git: keeping two bare repos in sync?

+1 vote
676 views

I just had the bare vs non-bare repo concept smack me in the face. Painful way to learn things, but I won't forget it any time soon. Since my remote repos are no longer work trees, how can I keep two bare repos in sync? This is primarily for DR purposes.

Here's more detail in case it'll help:
I have two rhel6 systems running git 1.7.1 that will be maintaining OS and web configuration files for a variety of teams, once I get the bugs in my understanding ironed out. One git server is in datacenter A (prod) where most of the updates will be occurring. Appropriate people will clone the bare repo, make their updates and push it back. The other git server is at our warm DR site. While rare, updates to this server should be possible.

I need to be able to fetch changes from the production git server and apply them to the DR one. When I tried it straight, I got the expected "fatal: This operation must be run in a work tree"

I suppose I could hack out a script to pull the configs down to a temp repo and push them back up to the DR one (and vice versa), but that seems like a kludge. As flexible and seemingly well thought out as git appears to be, I have to believe there's a better approach.

Could someone clue me in on what I'm missing or how a generic DR process is typically set up?

posted Oct 2, 2013 by Sanketi Garg

Looking for an answer?  Promote on:
Facebook Share Button Twitter Share Button LinkedIn Share Button

Similar Questions
+1 vote

I have git version 1.8.4.msysgit.0 installed. If I run this as a daemon, where are the repositories located? (i.e. where do i do a mkdir foo.git; cd foo.git; git init --bare?)

How do I change where the (server) repositories live?

+1 vote

I want to understand the best practice of organizing the GIT repositories. Let's say:
1. We are a large bank with many line of businesses and tons of application.
2. Each LOB has a large number of applications.

How many repositories shall I use? How do we organize the applications inside one repository? Any reference?

+5 votes

I read this page about git hook: http://git-scm.com/book/en/Customizing-Git-Git-Hooks and I still have some questions. I have a git server with some bare repos and I want create something like a continuos integration test so, I need to run a script when someone push on these repos. Main problem is that these repos are "bare" and doesn't contains any file. there is a way inside my script to "extract" files from a bare repo or i need to create a working copy?

If i create a separated working copy, how can i pull out this working copy inside my script? I tried something like this, but seems not working
cd /home/git/workingcopy/myawesomeappgit pull./run_test.sh

+5 votes

basically, I've got clones of some expensive-to-build projects (node.js), and I have changes that I want to rebase/cherry-pick onto dev and stable branches.

I know I can push to a remote, then pull into my other, and keep the two on different branches so the builds don't get out of date. But, I think I'd like it if they all just shared the same objects, branches, etc...

Could I symlink together my .git{branches,config,hoks,logs,objects,packed-refs,refs} directories? Is this just going to kill me later?

+3 votes

I'm trying to import our team's old subversion repository to git, but I'd like to retain the commit history. I tried 'git svn clone' but that only retrieves commits from the last copy onwards.

Because the svn setup is really bad, there is no way I can reproduce the "stdlayout" structure that 'git svn' likes, or any other structure where the trunk isn't a just few versions down from a copy.

Is there a way to have 'git svn' not do "--stop-on-copy" when fetching history? I'm perfectly fine with getting a simple linear history (because trying to do anything else with our svn setup will put our sanity in danger), but I couldn't find any documentation on how to do so.

...