2

To avoid git repositories growing too large, you sometimes need to run git gc on them. But this has some drawbacks, in particular it can consume lots of RAM. It looks to me like an alternative solution would simply be to clone the repository and replace the original copy with the clone. (These are bare repositories hosted on a server, so no working copy here.) This would cause more I/O but presumably use less RAM.

I'm guessing that probably this wouldn't have the same effect as git gc, but I'm not sure how. Hence the question: what is the difference between running git gc in a bare repository, versus running git clone, removing the repository, and replacing it by the clone?

1 Answer 1

4

There are a bunch of differences.

First of all, in order to just delete and clone, you have to assume that your copy of the repository is completely in sync with some remote copy and therefore it's possible to produce a better packed, but otherwise equivalent repository with a fresh clone. This is almost never the case, since repositories need not be in sync, and your local copy could have changes or branches you want to keep (even if it's bare). Doing a delete followed by a clone will lose all of this data, but a git gc will not.

Second, you can't assume that the server will intrinsically produce a good pack with good deltas on a clone. Most Git servers will spend more time packing data periodically with better settings, but will serve requests that must pack objects dynamically with settings that produce data faster but with poorer packing, since they must combine data from multiple packs and multiple pushes. So performing a periodic repack on your own may produce better results, sometimes very significantly so.

Third, a git gc can be done in place without causing an outage, while clone-and-replace cannot be done atomically on Unix (unless you use symlinks). git gc can also be done automatically as needed, while clone-and-replace cannot.

Fourth, if you rely on the ability to use reflogs to recover from a bad push or other mistake, clone-and-replace will lose that, while git gc will not.

Fifth, depending on your network connection, it may be faster to just run git gc than clone a new copy. For the reasons mentioned in the second point, you may end up transferring a lot more data, depending on how the repository is packed remotely, than you expect with a clone-and-replace.

In general, I'm not aware of anyone using clone-and-replace instead of repacking. In fact, folks with very large repositories tend to automatically fetch and preemptively pack to get better performance, not reclone all the time.

3
  • Thanks! There just seems to be a misunderstanding: in my question, the bare repository is the "master copy" of my repository (there is no "remote copy"). What I was suggesting is to clone the local copy that I have, hoping it would result in a better packing, not clone a remote copy. So I think the first and fifth point in your answer don't apply. But is there some hope that cloning a local repository like this will have some effects similar to git gc?
    – a3nm
    Apr 18, 2020 at 8:19
  • As mentioned, this isn't really what git clone is intended for. It may have the effects you desire, or it may not. If you want to maintain your repository, just run git gc. You will likely not save significant amounts of resources by cloning again.
    – bk2204
    Apr 18, 2020 at 17:19
  • I've had situations where I was short on space, needed to cut down on my copy of a large open source project, did not have any changes of my own in history, and git gc kept bombing due to malloc failures, where a remove and re-clone worked. Yes that's a lot of pre-conditions there, and you are right this is not normal, but in very rare cases it can work. Whether this fits the OPs case or not I am unable to discern.
    – user339730
    Apr 19, 2020 at 1:01

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.