Reputation: 2299

How to clone git repository from its zip

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

Upvotes: 66

Answers (6)

hellork

Reputation: 354

Update Instead of downloading zip or modifying git config, try --depth 1 from my other post at https://stackoverflow.com/a/79432692/10501192

git clone --depth 1 <repo_URI>
git fetch --unshallow 
git pull --all # do a git pull

My other solution was to clone the repo remotely and download a zip file of it. Don't do this unless there is no other way.

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.

Upvotes: 0

awiebe

Reputation: 3846

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.

Upvotes: 0

umläute

Reputation: 31314

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

Upvotes: 16

Arctelix

Reputation: 4576

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

Upvotes: 19

$fracjackmac$

fracjackmac

Reputation: 554

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.

Upvotes: 43

kostix

Reputation: 55523

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.

Upvotes: 3

How to clone git repository from its zip

Answers (6)

Related Questions