How to clone git repository from its zip

Asked 28/3, 2013 at 12:19 Answered 2/7 at 6:55

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..?

Emmie answered 28/3, 2013 at 12:19 Comment(3)

possible duplicate of How to complete a git clone for a big project on an unstable connection? – Uboat 28/3, 2013 at 13:3

You accepted an answer, but did it actually work? Seems to me clone --bare ... still downloads the large contents. – Corliss 31/12, 2019 at 10:28

yes, but that is equivalent to downloading the zip file. BTW you should have comment on the answer, not on the question :) – Emmie 2/1, 2020 at 10:0

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.

Hafner answered 3/8, 2015 at 6:49 Comment(4)

So the init see that you already have data about the repo? But basically you loose all history like a clone with 0 deep, right? I'll try this, if work I'll accept as correct answer. Thank you! – Emmie 3/8, 2015 at 8:45

Hi @lesto. Yes, the init sees the existing data about the repo, but as far as I can tell, the history is still included (unlike a simple clone). See my example above where I grabbed the zip file for [udacity/fullstack-nanodegree-vm ][1], followed the procedure, and then showed the log, which reflects all changes for this branch.[1]:github.com/udacity/fullstack-nanodegree-vm – Hafner 15/8, 2015 at 20:33

Forgot to mention that @o172.net's comment below was extremely helpful in figuring out what the bare repository really is. – Hafner 15/8, 2015 at 20:54

You have LOG history, but van you checkout the old version? Is it navigable in offline mode? I don't think so BUT it is more than enough for the request. Sorry but I still have to check by myself, but your answer will probably help a lot. – Emmie 15/8, 2015 at 21:2

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....

Exudation answered 28/3, 2013 at 12:49 Comment(5)

also tried from work but still unlucky.. uff but i can try to download the .git folder from http... so accepted as answer – Emmie 28/3, 2013 at 16:6

"In practice it seems that the "zip" downloads from github do not contain the .git directory" Didn't they used to? :( – Oddity 9/6, 2016 at 15:32

"In practice it seems that the "zip" downloads from github do not containt the .git directory, so this doesn't help" What's the point of leaving this answer then? – Mauer 12/11, 2016 at 13:33

Why is the .git directory necessary? – Elledge 5/9, 2019 at 11:3

@Elledge because the .git-directory contains the actual git repository (as opposed to just the files of at a given commit) – Desalinate 7/9, 2019 at 10:16

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 ;)

Dowry answered 12/8, 2016 at 2:38 Comment(6)

These steps work well. In addtion, I had to git merge with the allow-unrelated-histories option to keep the repo updated. – Espresso 25/8, 2018 at 16:47

Isn't that the same answer as from umläute? – Elledge 5/9, 2019 at 11:4

Nope. Umlaute’s answer does not work and this one does. The problem is the zip file has no git history. This solution creates a git history locally, then updates it from the remote. – Dowry 5/9, 2019 at 14:20

@arctelix I tried both yours and the accepted solution. But in both cases when I do git remote update or git pull as in the accepted solution it starts receiving the whole project again and starts Receiving object from 0. then the whole point of downloading zip becomes irrelevant. – Scyphus 29/12, 2019 at 15:30

@Scyphus did u try git fetch? because that apparently just gets the meta stuff – Swick 18/1, 2021 at 17:27

If you get this error at the last step error: Your local changes to the following files would be overwritten by checkout: you may commit and then checkout, this is worked with me. – Fidelis 23/1, 2021 at 23:59

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.

Pratfall answered 29/3, 2013 at 16:29 Comment(1)

NB a "bare" repository basically IS the .git directory. – Weigle 16/6, 2013 at 19:8

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.

Congruous answered 21/10, 2018 at 4:4 Comment(0)

Since my internet connection was too slow for git. What I wound up doing is cloning the repo remotely and downloading a zip file of that.

Free with a google account and collab worksheets.

Create Untitled.ipynb in google drive or use mine.
open the collab, and run remote commands, preceding them with !
After typing the command, press the Play button.

!git clone https://www.github.com/prusa3d/PrusaSlicer.git

Cloning into 'PrusaSlicer'...
warning: redirecting to https://github.com/prusa3d/PrusaSlicer.git/
remote: Enumerating objects: 235699, done.
remote: Counting objects: 100% (7388/7388), done.
remote: Compressing objects: 100% (1749/1749), done.
remote: Total 235699 (delta 5858), reused 6918 (delta 5626), pack-reused 228311
Receiving objects: 100% (235699/235699), 337.62 MiB | 22.56 MiB/s, done.
Resolving deltas: 100% (184073/184073), done.
Updating files: 100% (4285/4285), done.

The process is very fast.

Then simply zip it up. The copilot AI will suggest how to do it.

!zip -r PrusaSlicer.zip PrusaSlicer

You can download the zip directly from the worksheet but you need to set up googl collab on your machine. And it's a pain if you're on a public computer. Download it through Google Drive instead.

Open the panel on the left.
Mount your Google Drive.
Copy PrusaSlicer.zip to your google drive.
Download it from your Google Drive.

You could also try just zipping up the .git directory and see how it goes.

Or just work with the repo remotely, if you have a pro account. Use your laptop as a thin client for compiling, downloading dependencies, etc.

Casting answered 2/7 at 6:55 Comment(0)

Hot tags

Godot Unity Godot Help Programming Godot 4.X GUI GDScript 3D 2D Physics CSharp Godot 3.X VR XR Projects C++

Recommended topics

Hot tags