6

Title basically.

I just mixed some things up with my .gitignore and bloated my .git dir to > 100mb (it's a repo with like 100commits total..).

So I'm a lazy guy and was wondering if it would be possible to delete my history. I don't want to rebase something or stuff, I just want to shrink my .git dir size.

When there is no way to do this I just would git clone --depth 1 my repo to get the same effect.

boop
  • 7,413
  • 13
  • 50
  • 94
  • Why not just start a fresh repo with the files you want to keep? – Thilo Nov 25 '15 at 00:11
  • See also http://stackoverflow.com/questions/33906391/how-can-i-re-init-my-git-repo#comment55575386_33906391 – Thilo Nov 25 '15 at 00:24
  • @Thilo I don't see how the linked question is answering my question. I don't want to reinitialize my repository and much less `push -f` anything – boop Nov 25 '15 at 00:31
  • What is the difference between starting a new repo and throwing away all history? – Thilo Nov 25 '15 at 00:32
  • 0 votes for 11 months? Did I just wake up to alternative universe where disk space is infinite? – int_ua Nov 08 '16 at 01:35
  • Isn't this question duplicate of http://stackoverflow.com/questions/3797907/how-to-remove-unused-objects-from-a-git-repository ? – ymonad Nov 08 '16 at 02:24
  • @ymonad, they are close definitely, but still slightly different, IMO. This one is about bringing the state of .git folder to being identical to the state after `clone --depth 1` and that one is about cleaning specific files from .git folder and history if I understood it correctly. – int_ua Nov 08 '16 at 10:24

1 Answers1

1

Those are two conflicting goals:

  • delete the history implies a brand new repo (rm -Rf .git, git init .): that means you have to force push your new local repo with a git push --force, destroying the history on the remote repo as well,

  • keeping the remote repo intact means locally working with git clone --depth 1, which is safe to do since Git 2.0, as I have documented here (ie. you can push back to a remote repo from a local shallow repo)

The second approach seems the safest for:

  • preserving the remote repo
  • optimizing disk space locally

Note: for a local repo with its full history, git gc and git repack alone are not enough to really shrink the size of a .git folder.
See "git gc --aggressive vs git repack".

git gc
git repack -Ad      # kills in-pack garbage
git prune           # kills loose garbage

(That would not do much on a freshly cloned repo, that would only be effective on a local repo you have been working for some time) Plus, if you did in the past operations like git filter-branch, your .git folder would still keep a folder like .git/refs/original/ that you need to delete if you want to reduce the size of .git/.

AFAIU the original question and how I want to do it is precisely without removing .git folder, just removing local copy of git log data to make its' state identical to the state after git clone --depth 1

See "Converting git repository to shallow?"

You can try:

cd /my/repo
git show-ref -s HEAD > .git/shallow
git reflog expire --expire=0
git prune
git prune-packed
Community
  • 1
  • 1
VonC
  • 1,262,500
  • 529
  • 4,410
  • 5,250
  • AFAIU the original question and how I want to do it is precisely without removing .git folder, just removing local copy of git log data to make its' state **identical to the state after `git clone --depth 1`**. So far `gc` and `repack` reduced .git folder from 1.6G to 0.5G while with new clone it's <50Mb. And `prune` somehow returned it to 1.6G. – int_ua Nov 08 '16 at 10:16
  • Okay, looks like `git pull --depth 1` works on a simply clone repo and the 1.6Gb objects pack in the main one is somehow a stored difference because there is a different remote stored as "upstream" – int_ua Nov 08 '16 at 10:43
  • I still cannot remove the 1.6Gb pack by git commands even after deleting other remotes. – int_ua Nov 08 '16 at 10:50
  • @int and after a git remote prune upstream? – VonC Nov 08 '16 at 10:51
  • Good news: looks like "Converting git repo to shallow" is the question and the answer is right, i just didn't execute it correctly (merged conflict and forgot about it when setting shallow head) and broken my repo. But still, it looks like the right question and the right answer, thank you. I cannot award points yet, 15 hours left. – int_ua Nov 08 '16 at 10:55
  • I've already deleted the "upstream" remote but maybe it would've worked. – int_ua Nov 08 '16 at 10:57