Re: Git repository mesh?

From: Sergio <sergio.callegari@gmail.com>
Date: Nov 25, 2009, 08:42 UTC
Message-ID: <loom.20091125T092917-792@post.gmane.org>
In-Reply-To: <fcaeb9bf0911242007t1294bddej87b48691ea283e21@mail.gmail.com>

Nguyen Thai Ngoc Duy <pclouds <at> gmail.com> writes:

Show 15 quoted lines

> 
> Hi,
> 
> I work on a few machines so I have repositories on all of them. One
> repository can pull from or push to any other repositories (in case of
> push, it pushes on remote branches). I avoid a central repository
> because it's quite inconvenient when you just need to push some
> changes to a machine, you have to push it to the central repository
> then pull from that (and if the central repository is on WAN, double
> inconvenient). Maybe this model is just plain wrong, but it'd be fun
> to see if Git can work with this model.
> 
> The first thing that annoys me is remote repository management.
> Everytime I add a new repository to the mesh, I need to update .config
> of all repositories.

If I remember correctly, there was in the past the idea of allowing some limited shell variable substitution in the config file.

This would allow to have a single config for all the machines with remote entries. Something like

[remote "host1"]
        url = ssh://host1/path
        fetch = +refs/heads/*:refs/remotes/host1/*
        push = +refs/heads/*:refs/remotes/$hostname/*
[remote "host2"]
        url = ssh://host2/path
        fetch = +refs/heads/*:refs/remotes/host2/*
        push = +refs/heads/*:refs/remotes/$hostname/*
...

In other terms, admitting that all the candidate machines are known at the very start, you could start a repo on any of the host, placing in the config file all the possible hosts. Moreover, not needing to have a different config for each host may make it easier to manage (propagate by simple scp) or even to version control.

To the best of my knowledge the idea was not implemented in the end, but I think that a patch for variable substitution in the config file might still be found on the ML.

Sergio