threads / discuss / 15400

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

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

## tl;dr

7 messages between Sep 7, 2008 and Sep 10, 2008.

replies: 6people: 4as markdown or json

Ramagudi Naziir· Sep 7, 2008, 06:11 UTC · lore

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 implication I might not think of working this way. For example, maybe some of these little git files are named differently on each machine, and rsyncing them back and forth makes me piling a lot of clutter (in that case maybe git-gc will clean up everything). Or maybe something else horrid is going on and I really should just use git-push or pull.

I really prefer rsync to git-push/pull since it is much more easier - It's one command that syncs my whole working folder, including the git repositories..

Thanks a ton !! Naziir

(btw - I read tons of free/open source development mailing lists and I think that git has the best community by far. always so helpful and nice. so thanks for all the help thus far as well)

david@lang.hm· Sep 7, 2008, 06:27 UTC · re: Ramagudi Naziir · lore

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

On Sun, 7 Sep 2008, Ramagudi Naziir wrote:

Show 15 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
> implication I might not think of working this way. For example, maybe
> some of these little git files are named differently on each machine,
> and rsyncing them back and forth makes me piling a lot of clutter (in
> that case maybe git-gc will clean up everything). Or maybe something
> else horrid is going on and I really should just use git-push or pull.

the git files are names by their content so you don't need to worry about them being named differently

> I really prefer rsync to git-push/pull since it is much more easier -
> It's one command that syncs my whole working folder, including the git
> repositories..

the problems you can run into with rsync all end up related to one of two things.

1. what happens if the sync gets interrupted

2. what happens if the source gets updated during the sync

in your case these cannot happen without you knowing it, so you should be ok.

David Lang

Ramagudi Naziir· Sep 10, 2008, 06:31 UTC · re: david@lang.hm · lore

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

Hi David,

On Sun, Sep 7, 2008 at 9:27 AM,  <david@lang.hm> wrote:

Show 20 quoted lines

> On Sun, 7 Sep 2008, Ramagudi Naziir wrote:
>
>> 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
>> implication I might not think of working this way. For example, maybe
>> some of these little git files are named differently on each machine,
>> and rsyncing them back and forth makes me piling a lot of clutter (in
>> that case maybe git-gc will clean up everything). Or maybe something
>> else horrid is going on and I really should just use git-push or pull.
>
> the git files are names by their content so you don't need to worry about
> them being named differently

But can I end up having a lot of clutter ? e.g. if these files change, then rsync will copy the new files, and the old ones will still be kept, piling up like crud. is this correct ? is it problematic ? will git-gc fix it ?

david@lang.hm· Sep 10, 2008, 13:27 UTC · re: Ramagudi Naziir · lore

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

On Wed, 10 Sep 2008, Ramagudi Naziir wrote:

Show 28 quoted lines

> Hi David,
>
> On Sun, Sep 7, 2008 at 9:27 AM,  <david@lang.hm> wrote:
>> On Sun, 7 Sep 2008, Ramagudi Naziir wrote:
>>
>>> 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
>>> implication I might not think of working this way. For example, maybe
>>> some of these little git files are named differently on each machine,
>>> and rsyncing them back and forth makes me piling a lot of clutter (in
>>> that case maybe git-gc will clean up everything). Or maybe something
>>> else horrid is going on and I really should just use git-push or pull.
>>
>> the git files are names by their content so you don't need to worry about
>> them being named differently
>
> But can I end up having a lot of clutter ? e.g. if these files change,
> then rsync will copy the new files, and the old ones will still be
> kept, piling up like crud. is this correct ? is it problematic ? will
> git-gc fix it ?

git keeps copies of all the old files around anyway (that's it's purpose after all ;-)

when git gc runs it creates pack files to replace the individual files, but unless you run git gc --prune it does not remove anything and the individual files hang around.

so when you do the rsync back and forth you should have it delete files from the target that aren't on the source (or run git gc --prune afterwords)

David Lang

David Brown· Sep 7, 2008, 07:38 UTC · re: Ramagudi Naziir · lore

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

On Sun, Sep 07, 2008 at 09:11:47AM +0300, Ramagudi Naziir wrote:

>I really prefer rsync to git-push/pull since it is much more easier -
>It's one command that syncs my whole working folder, including the git
>repositories..

I used to do this quite a bit until after a few times I forgot to sync before changing things. I solved this by creating a bare repo I could push/pull from, and pushing one of them to it, then fetching and merging in the other.

After getting more familiar with git, I now use git with push/pull for pretty much anything I want synchronized. It nicely keeps track of what I've done, whereas it is easier with rsync, or even unison, to forget to do the sync.

David

Ramagudi Naziir· Sep 10, 2008, 06:35 UTC · re: David Brown · lore

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

Hi David,

On Sun, Sep 7, 2008 at 10:38 AM, David Brown <git@davidb.org> wrote:

Show 10 quoted lines

> On Sun, Sep 07, 2008 at 09:11:47AM +0300, Ramagudi Naziir wrote:
>
>> I really prefer rsync to git-push/pull since it is much more easier -
>> It's one command that syncs my whole working folder, including the git
>> repositories..
>
> I used to do this quite a bit until after a few times I forgot to sync
> before changing things.  I solved this by creating a bare repo I could
> push/pull from, and pushing one of them to it, then fetching and
> merging in the other.

can you please elaborate on this technique ? I don't really get it. You mean you have an empty git repository somewhere, with which you are synchronizing all other repositories ?

Show 5 quoted lines

>
> After getting more familiar with git, I now use git with push/pull for
> pretty much anything I want synchronized.  It nicely keeps track of
> what I've done, whereas it is easier with rsync, or even unison, to
> forget to do the sync.

so you have myriad of git repositories ? and you push/pull all of them every time you move to another station ? I also have a lot of git repositories, even for stuff other than source code projects.

thank you naziir

>
> David
>

Matthieu Moy· Sep 10, 2008, 07:05 UTC · re: Ramagudi Naziir · lore

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

"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