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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



"Ramagudi Naziir" <naziirr@xxxxxxxxx> writes:

> 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
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux