Shlomif's Technical Posts Community - Tech Tip: Mitigating “git clone”’s inability to be resumed using rsync [entries|archive|friends|userinfo]
Shlomif's Technical Posts Community

[ userinfo | livejournal userinfo ]
[ archive | journal archive ]

Links
[Links:| Shlomi Fish's Homepage Main Journal Homesite Blog Planet Linux-IL Amir Aharoni in Unicode open dot dot dot ]

Tech Tip: Mitigating “git clone”’s inability to be resumed using rsync [Jan. 2nd, 2014|02:43 pm]
Previous Entry Share Next Entry

shlomif_tech

[shlomif]
[Tags|, , ]
[Current Location |Home]
[Current Mood |Productive]
[Current Music |Chumbawamba - Tubthumping]

Happy new civil year, everyone. As you may know Git is a distributed version control system, but its often time-consuming (if the repository’s history is large) “git clone” operation cannot be resumed, which is a problem with bad Internet connections. There was a service that did “git clone” and then allowed people to download using HTTPS Called “Git bundler” but it has been down for sometime now. However, I found a different solution to the problem.

What can be done is use ssh to log in to a remote host, where the “git clone” is performed (preferably, but not absolutely necessarily, when running on top of a session of tmux, GNU Screen or similar). After that, you can use rsync over ssh to download the .git directory to the local workstation (I like to use the invocation rsync -a --progress -v --inplace for that).

Following that all you have to do is run git clone to a different directory to the one where you put the .git and set “git remote” appropriately.

Hope that helps, and the same can be done with other distributed version control systems such as Mercurial, or Bzr.

LinkReply