How to clone git repository from its zip
GitGithubZipGit CloneGit Problem Overview
I'm trying to clone a remote repository on github, but it is big and my connection doesn't seem to be stable enough, so I can't clone it successfully.
But I have successfully downloaded the .zip of the repository.
Is there a way to use this zip as it was created by git clone, so I can push, pull etc..?
Git Solutions
Solution 1 - Git
A related post here provides the information needed to grab the .git
directory and simplify the answer that umläute provided:
-
Grab the
.git
directory by cloning a bare repository$ mkdir repo $ git clone --bare http://github/user/repo repo
-
Make the
.git
directory and move the cloned files$ mkdir repo/.git $ mv repo/* repo/.git
-
Unzip the repository
$ unzip repo.zip
-
Re-initialize the repository
$ cd repo $ git init
-
Verify you're sync'ed
$ git pull
-
Reset the HEAD to clean up the status
$ git reset HEAD
-
Here's the log for the repo ... repo location - http://github.com/udacity/fullstack-nanodegree-vm
$ git log commit ebcbda650bc81d7f4856f5314a0689cea5b43086 Merge: 574774b b5b787e Author: Karl Krueger <[email protected]> Date: Tue Apr 7 11:39:54 2015 -0700` Merge pull request #3 from pmallory/sharedDirAlert Add a login alert to explain how to access Vagrant's shared directory commit b5b787efdb1ecec0c3c9c7f9c0fd4732f984fcb3 Author: Philip Mallory <[email protected]> Date: Mon Apr 6 15:40:32 2015 -0700` move the alert into the motd commit b8012f33c86b0d19fc4c2b972af092e88d00978f Author: Philip Mallory <[email protected]> Date: Mon Apr 6 14:32:01 2015 -0700` Add a login alert to explain how to access Vagrant's shared directory commit 574774ba29ccd661154431d5600240f090440c37 Author: Lorenzo Brown <[email protected]> Date: Wed Mar 11 14:08:02 2015 -0700` Update pg_config.sh Added installs for Auth&Auth commit 88fc5537b1a0017a1d76af4587a22412473809a4 Author: Lorenzo Brown <[email protected]> Date: Wed Mar 4 13:00:25 2015 -0800` Update and rename vagrant to vagrant/catalog/README.txt commit f978cdc14c62b7295d8da1a95452faaa1bd108b8 Author: Lorenzo Brown <[email protected]> Date: Wed Feb 4 11:06:03 2015 -0800` Update Vagrantfile switched to port forwarding on 8080 commit d6a3a26578ef3c6d01d28abca76d817938892c7f Author: Lorenzo Brown <[email protected]> Date: Tue Feb 3 14:52:34 2015 -0800` Update Vagrantfile Added: config.vm.network "forwarded_port", guest: 80, host: 8080 config.vm.network "forwarded_port", guest: 5000, host: 5000 FSF uses these two ports for lessons 2 & 3 respectively. commit 752a79e408c7328ef7f1766d1b97bb468ffed90a Author: Mike Wales <[email protected]> Date: Mon Feb 2 11:21:29 2015 -0800` Removed .vagrant directory commit 5af9d19adf9ab19b1d886f6cc78e556f864b42dd Author: Mike Wales <[email protected]> Date: Mon Feb 2 11:16:45 2015 -0800` Initial commit.
Solution 2 - Git
If you have downloaded the repository (including the.git
dir), it's quite simple.
-
unzip the repository
$ unzip repo.zip
-
configure a
remote
in your repository that points to the clone URI$ cd repo $ git init $ git remote add origin https://github.com/user/repo.git
-
resync the repositories
$ git pull
In practice, it seems that the "zip" download from github does not contain the .git
directory, so this doesn't help :-(
Probably the best bet you have is to do a clone on a machine that does have stable access, and then zip the .git directory and fetch that somehow....
Solution 3 - Git
While the accepted answer does the trick, this seems a bit more straight forward.
unzip <repo>.zip
cd <repo>
git init
git add .
git remote add origin https://github.com/<user>/<repo>.git
git remote update
git checkout master
Just make sure to replace <user>
& <repo>
with your github user name and your repo name ;)
Solution 4 - Git
The only zip-like alternative to cloning is exchanging "bundles", but I'm afraid github does not offer creation/downloading of bundles.
A zip archive downloadable from github is just a snapshot of one particular commit of your repository history (usually the tip of a branch), and it doesn't contain any history — this facility is intended to automatically provide the users of your code base (not developers!) with a way to conveniently download a snapshot of the project's source code. Note that mere users and, say, downstream maintainers packaging your software for operating systems, do not usually clone whole histories but rather work with tarballs.
In other words, downloading a zip archive works like running git archive
on the remote side and then passing you the resulting file.
Also note that repositories hosted on github (and other Git hosting providers) are "bare", that is, they do not contain the ".git" subdirectory.
In any case, seems like your only way to solve this is to find a fast and reliable link and do your initial download using it.
But note that things change if you're okay with not having the full history. You can then use the so-called "shallow cloning", by passing the "--depth" command-line parameter to git clone
.
Solution 5 - Git
Initialization might not be the way to go depending on your use case. It will be especially tedious if there is a very big repository(mine was 16GB and Ineeded to do this), and in fact will blow away local refs+objects
which is no good if your archive represents an archive for which a remote no longer exists.
You need the repository to be copied in two steps:
- "Data Files" (HEAD Revision possibly unstaged)
- Indices and Objects ie. history+refs+objects :This records your baseline, deltas, branch pointers and tags.
The objective is to reduce how many object must be cloned from a remote or which cannot be recreated from a remote which no longer exists. Additionally you want your config to not conflict with the local config files of whoever initially created the repository
You want to preserve the repository layout for objects and refs which not longer exist in the remote or which you don't want to copy (e.g they're large image assets). For this reason you don't want to init and pull, especially if you don't have a remote anymore.
Instead the repository is already in an acceptable state with refs and objects intact. The only problems may be if the remotes are no longer setup properly and your config may be set improperly.
Run git config --local -l
to verify that the commit identity is not set locally in the repository and change any keys which override your global settings in a way you don't want.
Now that it's configured treat the repository now as if it were your own(because it is), git is designed to work distributed so once you alter any local config, it is effectively no different, than as if it were cloned. The only thing remaining is you have to insure your remotes are setup properly.
If you do not have remote but wish to create one, create it on the remote server using git init --bare
then add a remote as usual and push all refs git push --all
. Making a repository bare means it will accept the first push without complaining about a diverged history.
If you have an existing remote repository, add it as a remote and pull. The archive branches may be pointing to the wrong url depending how long ago the archive was made, if this is the case, use git remote
to assign them to new locations or remove any dead urls.
Once remotes have been setup fetch and pull to get up to date. If there is a detached HEAD, checkout the desired branch. If the history of the archived repository has diverged from the remote, git will produce a merge conflict, resolve as normal, stashing changes if necessary.