53

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

Lesto
  • 2,083
  • 2
  • 17
  • 25
  • 3
    possible duplicate of [How to complete a git clone for a big project on an unstable connection?](http://stackoverflow.com/questions/3954852/how-to-complete-a-git-clone-for-a-big-project-on-an-unstable-connection) – kan Mar 28 '13 at 13:03
  • You accepted an answer, but did it actually work? Seems to me `clone --bare ...` still downloads the large contents. – Benny Bottema Dec 31 '19 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 :) – Lesto Jan 02 '20 at 10:00

5 Answers5

36

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 <karl@udacity.com>
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 <philip@udacity.com>
Date:   Mon Apr 6 15:40:32 2015 -0700`

       move the alert into the motd

commit b8012f33c86b0d19fc4c2b972af092e88d00978f
Author: Philip Mallory <philip@udacity.com>
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 <lorenzo@udacity.com>
Date:   Wed Mar 11 14:08:02 2015 -0700`

       Update pg_config.sh

       Added installs for Auth&Auth

commit 88fc5537b1a0017a1d76af4587a22412473809a4
Author: Lorenzo Brown <lorenzo@udacity.com>
Date:   Wed Mar 4 13:00:25 2015 -0800`

       Update and rename vagrant to vagrant/catalog/README.txt

commit f978cdc14c62b7295d8da1a95452faaa1bd108b8
Author: Lorenzo Brown <lorenzo@udacity.com>
Date:   Wed Feb 4 11:06:03 2015 -0800`

       Update Vagrantfile

       switched to port forwarding on 8080

commit d6a3a26578ef3c6d01d28abca76d817938892c7f
Author: Lorenzo Brown <lorenzo@udacity.com>
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 <michael.wales@udacity.com>
Date:   Mon Feb 2 11:21:29 2015 -0800`

       Removed .vagrant directory

commit 5af9d19adf9ab19b1d886f6cc78e556f864b42dd
Author: Mike Wales <michael.wales@udacity.com>
Date:   Mon Feb 2 11:16:45 2015 -0800`

       Initial commit.
Community
  • 1
  • 1
fracjackmac
  • 484
  • 4
  • 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! – Lesto Aug 03 '15 at 08: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]:http://github.com/udacity/fullstack-nanodegree-vm – fracjackmac Aug 15 '15 at 20:33
  • Forgot to mention that @[o172.net](http://stackoverflow.com/users/997708/o172-net)'s comment below was extremely helpful in figuring out what the ___bare___ repository really is. – fracjackmac Aug 15 '15 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. – Lesto Aug 15 '15 at 21:02
16

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

devsaw
  • 940
  • 1
  • 12
  • 24
umläute
  • 23,410
  • 4
  • 50
  • 99
  • also tried from work but still unlucky.. uff but i can try to download the .git folder from http... so accepted as answer – Lesto Mar 28 '13 at 16:06
  • "In practice it seems that the "zip" downloads from github do not contain the .git directory" Didn't they used to? :( – endolith Jun 09 '16 at 15:32
  • 2
    "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? – Anwar Nov 12 '16 at 13:33
  • Why is the `.git` directory necessary? – Adam Sep 05 '19 at 11:03
  • @Adam because the `.git`-directory contains the actual *git repository* (as opposed to just the files of at a given commit) – umläute Sep 07 '19 at 10:16
12

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

Arctelix
  • 4,165
  • 2
  • 22
  • 36
  • These steps work well. In addtion, I had to `git merge` with the `allow-unrelated-histories` option to keep the repo updated. – devsaw Aug 25 '18 at 16:47
  • Isn't that the same answer as from `umläute`? – Adam Sep 05 '19 at 11:04
  • 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. – Arctelix Sep 05 '19 at 14:20
  • 1
    @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. – Tee Dec 29 '19 at 15:30
  • @Tee did u try git fetch? because that apparently just gets the meta stuff – Hadi Pawar Jan 18 '21 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. – Mohamed ElSawaf Jan 23 '21 at 23:59
3

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.

kostix
  • 43,267
  • 10
  • 69
  • 137
0

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.

awiebe
  • 3,257
  • 3
  • 18
  • 31