{"thread":{"id":"32588","subject":"Turning a complete repository to a shallow one","startedAt":"2013-01-11T04:40:03Z","lastAt":"2013-01-11T04:53:01Z","messageCount":2,"participants":["Duy Nguyen","Junio C Hamano"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"206495","messageId":"CACsJy8Bv+AfDbttFdJ5a0PaoMrMtv1seda7VqLpfdevR4BMj4A@mail.gmail.com","threadId":"32588","inReplyTo":null,"subject":"Turning a complete repository to a shallow one","fromName":"Duy Nguyen","fromEmail":"pclouds@gmail.com","sentAt":"2013-01-11T04:40:03Z","receivedAt":"2013-01-11T04:40:03Z","isPatch":false,"sender":{"key":"pclouds@gmail.com","avatar":"https://avatars.githubusercontent.com/u/720?v=4"},"body":"Apparently we could do it:\n\ngit clone --single-branch git.git\ncd git\ngit tag -l|xargs git tag -d\ngit fetch --depth=1 origin master\ngit repack -ad\n\nNow the repository becomes shallow and all of history is _lost_. It is\na feature for those who wants to reduce disk usage, but it's also a\ngun to shoot at your feet. I'm tempted to ban this case. If I want to\nreduce disk usage, I should be forced to shallow clone it first, then\nremove the original repository. I still have a complete repository if\nI change my mind. And \"rm -rf git\" is alarming enough for me to think\nit twice before executing.\n\nComments?\n-- \nDuy\n"},{"id":"206496","messageId":"7vk3rkcocy.fsf@alter.siamese.dyndns.org","threadId":"32588","inReplyTo":"CACsJy8Bv+AfDbttFdJ5a0PaoMrMtv1seda7VqLpfdevR4BMj4A@mail.gmail.com","subject":"Re: Turning a complete repository to a shallow one","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2013-01-11T04:53:01Z","receivedAt":"2013-01-11T04:53:01Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Duy Nguyen <pclouds@gmail.com> writes:\n\n> Apparently we could do it:\n>\n> git clone --single-branch git.git\n> cd git\n> git tag -l|xargs git tag -d\n> git fetch --depth=1 origin master\n> git repack -ad\n\nI may have been unclear in the earlier message, but this is one of\nthe reasons why I think \"fetch --depth\" is misadvertised (it says\n\"deepen the history\", when the real thing it does is to truncate to\nthe new depth counting from the updated tip), and misdesigned (it\nforces the user to guess what the new depth should be).  It should\nbe advertised correctly, as a way to reset its depth starting from\nthe current history (and of course --depth=1 is truncates).\n\nWe should introduce a separate \"fetch --deepen\" that does what\nnormal people would want (see my earlier message with ASCII art).\n"}]}