git-gc

I have a recurring issue where my git repo (I think?) will decide it needs to garbage collect. This process takes well over a half hour, and will then trigger on every pull/push operation. Running Git GC manually takes a half hour, but doesn't seem to fix the issue. The only solution I have found is to delete my repo and clone fresh, which is suboptimal for any number of reasons. My git GC operations may be slow because I have set git some memory limits to stop it from crashing out on git GC operations, as it used to do when it hit the 4gb windows memory limit and then crapped out. Any help

Is there any difference between git gc and git repack -ad; git prune ? If yes, what additional steps will be done by git gc (or vice versa)? Which one is better to use in regard to space optimization or safety? Is there any difference between git gc and git repack -ad; git prune ? The difference is that by default git gc is very conservative about what housekeeping tasks are needed. For example, it won't run git repack unless the number of loose objects in the repository is above a certain threshold (configurable via the gc.auto variable). Also, git gc is going to run more tasks than just git

Simple question, I'm trying to run git gc on a machine with a quota. Pre-gc, I'm at about 18GB of usage, almost all of which is my cloned git repository. My disk limit is 25GB. During the git gc operation, enough temporary files are written to disk to hit my limit and thus cause the git gc operation to fail. I can delete the .git/objects/pack/tmp_pack_* after the failed operation and get back down to 18GB of usage, but I'd really like to actually complete git gc and reclaim a little performance. Is there some fancy option (or series of other git commands) that I can use that doesn't involve

I'm working on a git course and wanted to mention that lost refs are not really lost until running git gc . But verifying this, I found out that this is not the case. Even after running git gc --prune=all --aggressive the lost refs are still there. Clearly I misunderstood something. And before saying something incorrect in the course, I want to get my facts straight! Here is an example script illustrates the effect: #!/bin/bash git init # add 10 dummy commits for i in {1..10}; do date > foo.txt git add foo.txt git commit -m "bump" foo.txt sleep 1 done; CURRENT=$(git rev-parse HEAD) echo HEAD

I have a @daily job in the crontab that runs git gc on all the repos. I'm trying to set up a log file for the job but I/O redirection does not produce the results I am looking for; I get a blank file. I've done all the usual > , 2>&1 and so on without any success. Someone mentioned to me that git gc uses ncurses for its output procedures which throws output directly to the console, thus bypassing stdout/stderr (correct me if I'm wrong here). Can some one point me in the right direction? You can try this: script -q -c 'git gc' > log Or this (with more readable output): script -q -c 'git gc' |

What's going on in background when launching, git gc git prune Output of git gc : Counting objects: 945490, done. Delta compression using up to 4 threads. Compressing objects: 100% (334718/334718), done. Writing objects: 100% (945490/945490), done. Total 945490 (delta 483105), reused 944529 (delta 482309) Checking connectivity: 948048, done. Output of git prune : Checking connectivity: 945490, done. What is the difference between these two options? Thank you TL;DR git prune only removes loose, unreachable, stale objects (objects must have all three properties to get pruned). Unreachable packed