# Turning a complete repository to a shallow one 2 messages from 2013-01-11 to 2013-01-11. Participants: Duy Nguyen, Junio C Hamano. Thread: https://gitlist.dev/t/32588 ## Duy Nguyen, 2013-01-11 04:40 Subject: Turning a complete repository to a shallow one Message-ID: URL: https://gitlist.dev/e/CACsJy8Bv%2BAfDbttFdJ5a0PaoMrMtv1seda7VqLpfdevR4BMj4A%40mail.gmail.com ``` Apparently we could do it: git clone --single-branch git.git cd git git tag -l|xargs git tag -d git fetch --depth=1 origin master git repack -ad Now the repository becomes shallow and all of history is _lost_. It is a feature for those who wants to reduce disk usage, but it's also a gun to shoot at your feet. I'm tempted to ban this case. If I want to reduce disk usage, I should be forced to shallow clone it first, then remove the original repository. I still have a complete repository if I change my mind. And "rm -rf git" is alarming enough for me to think it twice before executing. Comments? -- Duy ``` ## Junio C Hamano, 2013-01-11 04:53 Subject: Re: Turning a complete repository to a shallow one Message-ID: <7vk3rkcocy.fsf@alter.siamese.dyndns.org> URL: https://gitlist.dev/e/7vk3rkcocy.fsf%40alter.siamese.dyndns.org In-Reply-To: ``` Duy Nguyen writes: > Apparently we could do it: > > git clone --single-branch git.git > cd git > git tag -l|xargs git tag -d > git fetch --depth=1 origin master > git repack -ad I may have been unclear in the earlier message, but this is one of the reasons why I think "fetch --depth" is misadvertised (it says "deepen the history", when the real thing it does is to truncate to the new depth counting from the updated tip), and misdesigned (it forces the user to guess what the new depth should be). It should be advertised correctly, as a way to reset its depth starting from the current history (and of course --depth=1 is truncates). We should introduce a separate "fetch --deepen" that does what normal people would want (see my earlier message with ASCII art). ```