git + unison

git + unison

[Matthieu Moy]

Hi,

I'm wondering how dangerous the interaction of git with the unison
file synchronizer[1] can be.

Another way of asking the question can be: what's the best way to
keep two machines with many git repositories in sync?

Unison is a userland application that does bi-directional
synchronization of two directories. Typically, to keep a laptop and a
desktop synchronized (modify a file on the desktop and another on the
laptop, unison will copy the files). I find it very usefull to keep
large directories containing unrelated projects (typically,
~/teaching/, ~/research, ..., my colleagues even synchronize $HOME on
their laptops) in sync between two machines.

Actually, git achives something similar (and lot more, of course):
modify a file here, commit, modify another there, commit, and then
push & pull can do the sync. I find git excellent to manage somehow
self-contained projects (~/teaching/2007-2008/whatever-course/), but
inappropriate for $HOME or such big containers (need to run more
commands, disk-space overhead, ...).

So, at the moment, I have both unison and git. My fear is that unison
touches the content of the .git/ directories. So, for example, if I
commit on one side, and commit something else on the other side, I'll
get unison conflicts at least on .git/refs/heads/master and
.git/index, and resolving the conflict in favor of either side leads
to dangling objects whith important content.

What I'm doing right now is that I try to make sure I don't run unison
when trees have diverged, which is not really satisfactory since 1) I
can be wrong, and a miss-synchronization could lead to data-loss, and
2) that means not really taking advantage of unison.


What about you? What do you use to synchronize your laptop and
desktop, or home and office? Anybody using unison and git on the same
filesystem?

Thanks for your hints,

-- 
Matthieu

[1] : http://www.cis.upenn.edu/~bcpierce/unison/

Re: git + unison

[Remi Vanicat]

Matthieu Moy <Matthieu.Moy@imag.fr> writes:

> Hi,
>
[...]
Note that I do use I do use both unison and git, but I don't use
unison on git repository (I use git to synchronize git repository).

> So, at the moment, I have both unison and git. My fear is that unison
> touches the content of the .git/ directories. So, for example, if I
> commit on one side, and commit something else on the other side, I'll
> get unison conflicts at least on .git/refs/heads/master and
> .git/index, and resolving the conflict in favor of either side leads
> to dangling objects whith important content.

Well, at least with my configuration, when a file have been change on
both side, unison offer the possibility to transfer one way or the
other or to do nothing. I believe that if this happen, the correct
procure is to use git tool to merge (as git is better for merging
than unison, even more when we are speaking about git repository)

>
> What I'm doing right now is that I try to make sure I don't run unison
> when trees have diverged, which is not really satisfactory since 1) I
> can be wrong, and a miss-synchronization could lead to data-loss, and
> 2) that means not really taking advantage of unison.

Well, as I've already said, I use unison in an interactive way, so if
a file have been changed in both side, unison say it, ask me what to
do. So I can choose to do nothing, and to stop unison right away to
use a better tool for this task.





-- 
Rémi Vanicat

Re: git + unison

[J. Bruce Fields]

On Sun, Dec 02, 2007 at 06:59:36PM +0100, Matthieu Moy wrote:
> What about you? What do you use to synchronize your laptop and
> desktop, or home and office? Anybody using unison and git on the same
> filesystem?

I just have a subdirectory of my home directory "local" that I tell
unison not to synchronize:

	ignore = Path local

and keep all my git repos there, relying on git itself when I need to
distribute stuff--generally all my repos are associated with public
repos on a single (regularly backed-up) server, and I try not to let any
work accumulate in any particular repository for long without being
pushed to a branch in its public repo.

--b.