How to clone git repository from its zip

GitGithubZipGit Clone

Git 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:

  1. "Data Files" (HEAD Revision possibly unstaged)
  2. 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.

Attributions

All content for this solution is sourced from the original question on Stackoverflow.

The content on this page is licensed under the Attribution-ShareAlike 4.0 International (CC BY-SA 4.0) license.

Content TypeOriginal AuthorOriginal Content on Stackoverflow
QuestionLestoView Question on Stackoverflow
Solution 1 - GitfracjackmacView Answer on Stackoverflow
Solution 2 - GitumläuteView Answer on Stackoverflow
Solution 3 - GitArctelixView Answer on Stackoverflow
Solution 4 - GitkostixView Answer on Stackoverflow
Solution 5 - GitawiebeView Answer on Stackoverflow