Clone git repository without keeping revisions locally

Question

Is it possible to clone a repository in git and not keep all the revisions?

My repository is large (tens of GB). I don't want to double the storage space in a working copy. I just want the files and to know where to go to push/pull updates. Is this even possible with git or do I need to return to subversion?

Answer 1

You can create a "shallow" clone, but it makes a read only repository in that you can't fetch from nor push into it. Here is the command: git clone repoUrl.git --depth 1 --branch branch_name

Answer 2

I think the closest you're going to get here is to use the --depth option to git clone to limit the amount of history that gets pulled in. It also means that you wont have all the history available for git log and friends--and you can't run git log against a remote repository.

That said, there are some other bits to consider. Git does attempt to pack like objects together, giving it good compression when build packs. This does mean that the files themselves need to be similar in some way though. This works great for source code, but it may be less great with some of your binary formats.

Git is also not that great with large files. Git tends to load entire files into memory, though there have been some efforts to reduce that. So you may want to do some testing to make sure you aren't going to run into any edges there.

Answer 3

Is it possible to clone a repository in git and not keep all the revisions?

With not so very much discipline you can use --reference repositories to keep just one depot sitewide for the big, stable parts of a repo, where "site" is defined as "machines with access to a common shared filesystem".

To make it as safe as your shared filesystem:

1. Make a bare repo that publishes only stable references. Easiest may be to make a full clone and then delete all the unstable ones.

   git clone --bare u://r/l/to/real/upstream /path/to/reference/repo
cd !$
git tag -d all the tags that have even a whiff of instability about them
git branch -D every branch
git rev-parse any-tag > HEAD

2. Use this repo as a reference. When cloning the real upstream,

   git clone --reference /path/to/reference/repo

And that's really all there is to using it in-house. The discipline part is, you have to be sure the filesystem with your depot on it is always available to anything referencing it, and that no change to your depot ever leaves an unreferenced commit. chmod -R aw will do that nicely.

If people clone this way to their laptops and take them somewhere without access to the depot, they need to disconnect their clones from the depot first:

# disconnect from depot:
git repack -Ad \
&& rm .git/objects/info/alternates

---

Notes:

For really underpowered laptops and really large repos, the repacking might be inconvenient. An alternate way is:

# disconnect from depots, minimal cpu load for underpowered localhost:
cp -r $(cat .git/objects/info/alternates) .git \
&& rm .git/objects/info/alternates

It's also possible to pack up "just what you need" for a road trip with git pack-objects and git rev-list . Here's one way to do it:

# pack up what I have locally, mark it as reliably-present:

git repack -l
for pack in .git/objects/pack/*.pack; do 
    touch $pack.keep
done

# pack up everything I still don't have that might actually be useful
# no need to list tags that are ancestors of other tags here:

git rev-list --objects --all ^tag-I-dont-need ^another ^etc \
| git pack-objects --honor-pack-keep .git/objects/pack/pack
mv .git/objects/info/alternates{,.inaccessible}

# let git gc at what's here when needed
rm .git/objects/pack/pack-*.keep

and on return to the fold, put the alternates file back.

Answer 4

If the clone is going to be on the same filesystem volume, then use git clone --local .

It uses hard-links to save space.

Look it up in the git-clone man page.

This means you can have the full history, without doubling the space requirement.