Re: rsync vs. git-push/pull ? (+kudus)

From: Matthieu Moy <matthieu.moy@imag.fr>
Date: Sep 10, 2008, 07:05 UTC
Message-ID: <vpqej3sa3bb.fsf@bauges.imag.fr>
In-Reply-To: <dfb262380809062311i3fffb900m5d73f5396b403dbe@mail.gmail.com>

"Ramagudi Naziir" <naziirr@gmail.com> writes:

Show 10 quoted lines

> Hi all,
>
> I have several local git repositories on my machine. I'm the only
> user, and use them only locally. Now, sometimes when I need to work
> remotely, I just rsync my repositories to my laptop, and keep working
> there. When I finish (few hours, days or sometimes weeks later), I
> just rsync everything back to my local git repositories on my main
> workstation, and continue working there.
>
> Now I was wondering whether it's OK or whether there are bad

Clearly, it's more risky to use rsync: git knows which repository is ahead of the other, knows it has to do a merge in case the two diverged, ... but if you really know what you're doing, this should be OK.

Technically, there's at least one case which can be problematic if you "rsync" without "--delete": packed references. For example, the tip of the master branch is normally stored in .git/refs/heads/master, but after packing, git removes this file, and puts all the references in .git/packed-refs (so it's just 1 file, eats less inodes, less round-trips for HTTP fetch, ...). Then, if .git/refs/heads/master is re-created, it takes precedence over .git/packed-refs. So if you "git gc" locally, and then "rsync remote/ local/", you'll end up with an old .git/refs/heads/master that overrides the new .git/packed-refs, and git will behave as if you went backwards in history.

Easily fixable, but I've been hit by this once and took time to understand what was happening ;-).

-- 
Matthieu