{"thread":{"id":"12900","subject":"Truncating and cleaning a imported git repositary to make it more usable","startedAt":"2008-03-28T12:35:16Z","lastAt":"2008-03-31T06:17:38Z","messageCount":14,"participants":["Alex Bennee","Avery Pennarun","Johannes Sixt","Jeff King","Mike Hommey","Jakub Narebski","Michael Haggerty"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"73252","messageId":"1206707716.9819.15.camel@malory","threadId":"12900","inReplyTo":null,"subject":"Truncating and cleaning a imported git repositary to make it more usable","fromName":"Alex Bennee","fromEmail":"kernel-hacker@bennee.com","sentAt":"2008-03-28T12:35:16Z","receivedAt":"2008-03-28T12:35:16Z","isPatch":false,"sender":{"key":"kernel-hacker@bennee.com","avatar":null},"body":"Hi,\n\nI've succeeded in porting our whole CVS repository into git (with plenty\nof swap, cvsps is very memory hungry). Now we have a reference\nhistorical repository I need to think about creating one we actually use\nfor day to day use (the .git is currently in the order of 650Mb which is\na little heavy for pushing around DSL links willy nilly).\n\nWhat I need to achieve is fairly simple.\n\n1. Find the common ancestor point for all the product branches I want to\nkeep in the repo.\n\nCan anyone point me to the magic invocation that would allow this?\ngit-merge-base can find the common point for two commits, do I just have\nto iteratively use that?\n\nI'm currently working over a terminal link so it would be dead handy if\nthere was a visual way of showing what gitk --all does on the command\nline.\n\n2. Create a new repo, starting at the common ancestor point\n\n 2(a). I'd need to remove the orphaned old CVS modules which are still\naround but not referenced any more.\n\n3. Create the product branches and import ANCESTOR..BRANCH_HEAD into\nthem\n\nI'm not sure if I could pull directly into the new repo here. I could do\nit by doing a:\n\n old_repo: git-format-patch ANCESTOR..BRANCH_HEAD\n new_repo: git-am ../old_repo/0*\n\nBut I'm open to newer cleaner ways of dealing with this.\n\nHas anyone done this before? Are there cleaner ways of dealing with\nthis?\n\n--\nAlex, homepage: http://www.bennee.com/~alex/\nWhen one knows women one pities men, but when one studies men, one\nexcuses women. -- Horne Tooke\n"},{"id":"73253","messageId":"32541b130803280550u2ed23b5auc84bf935d5344e84@mail.gmail.com","threadId":"12900","inReplyTo":"1206707716.9819.15.camel@malory","subject":"Re: Truncating and cleaning a imported git repositary to make it more usable","fromName":"Avery Pennarun","fromEmail":"apenwarr@gmail.com","sentAt":"2008-03-28T12:50:37Z","receivedAt":"2008-03-28T12:50:37Z","isPatch":false,"sender":{"key":"apenwarr@gmail.com","avatar":"https://avatars.githubusercontent.com/u/20592?v=4"},"body":"On 3/28/08, Alex Bennee wrote:\n> I've succeeded in porting our whole CVS repository into git (with plenty\n> of swap, cvsps is very memory hungry). Now we have a reference\n> historical repository I need to think about creating one we actually use\n> for day to day use (the .git is currently in the order of 650Mb which is\n> a little heavy for pushing around DSL links willy nilly).\n\nYou used git-repack and git-gc, right? If not, the repo will be\nbigger than it should be.\n\n> 1. Find the common ancestor point for all the product branches I want to\n> keep in the repo.\n>\n> Can anyone point me to the magic invocation that would allow this?\n> git-merge-base can find the common point for two commits, do I just have\n> to iteratively use that?\n>\n> I'm currently working over a terminal link so it would be dead handy if\n> there was a visual way of showing what gitk --all does on the command\n> line.\n\n\"git show-branch -a\" probably does what you want.\n\n> 2. Create a new repo, starting at the common ancestor point\n>\n> 2(a). I'd need to remove the orphaned old CVS modules which are still\n> around but not referenced any more.\n>\n> 3. Create the product branches and import ANCESTOR..BRANCH_HEAD into\n> them\n\nYou probably want to look at git-filter-branch, particularly the\n--parent-filter option.\n\nNote that 2(a) would be easiest if you just did it before importing\nfrom CVS at all, since it's easy to remove old modules from CVS just\nby moving the files out of the way.\n\nHave fun,\n\nAvery\n"},{"id":"73257","messageId":"b2cdc9f30803280608y501147c0tc02f43196bda4bf7@mail.gmail.com","threadId":"12900","inReplyTo":"32541b130803280550u2ed23b5auc84bf935d5344e84@mail.gmail.com","subject":"Re: Truncating and cleaning a imported git repositary to make it more usable","fromName":"Alex Bennee","fromEmail":"kernel-hacker@bennee.com","sentAt":"2008-03-28T13:08:05Z","receivedAt":"2008-03-28T13:08:05Z","isPatch":false,"sender":{"key":"kernel-hacker@bennee.com","avatar":null},"body":"On Fri, Mar 28, 2008 at 12:50 PM, Avery Pennarun wrote:\n> On 3/28/08, Alex Bennee wrote:\n> > I've succeeded in porting our whole CVS repository into git (with plenty\n> > of swap, cvsps is very memory hungry). Now we have a reference\n> > historical repository I need to think about creating one we actually use\n> > for day to day use (the .git is currently in the order of 650Mb which is\n> > a little heavy for pushing around DSL links willy nilly).\n>\n> You used git-repack and git-gc, right? If not, the repo will be\n> bigger than it should be.\n\nOh yes. Unfortunately for 7 years of development of an embedded\nplatform there is a lot of cruft in the CVS repo :-(.\n\nHowever as it needs to be a drop in replacement for the current repo\nwe can't just drop all the history and start from a fresh repo.\n\n> > 1. Find the common ancestor point for all the product branches I want to\n> > keep in the repo.\n\n> \"git show-branch -a\" probably does what you want.\n\nCool. Or in fact git-show-branch --merge-base seems to be the baby.\n\nI'm sure it's been mentioned before but the plethora of git commands\ncan make it hard to find the commands you want even\nif your sure there is some way of doing it :-)\n\n> > 2. Create a new repo, starting at the common ancestor point\n> >\n> > 2(a). I'd need to remove the orphaned old CVS modules which are still\n> > around but not referenced any more.\n> >\n> > 3. Create the product branches and import ANCESTOR..BRANCH_HEAD into\n> > them\n>\n> You probably want to look at git-filter-branch, particularly the\n> --parent-filter option.\n>\n> Note that 2(a) would be easiest if you just did it before importing\n> from CVS at all, since it's easy to remove old modules from CVS just\n> by moving the files out of the way.\n\nTrouble is looking at the current repo I'm not sure which modules are\norphans (at the common anscestor point) and which have been added\nsince.\n\nOf course now I can easily go back in time (easier than in CVS) I can\nbuild up this list.\n\n> Have fun,\n\nFor certain values of fun ;-)\n\n-- \nAlex, homepage: http://www.bennee.com/~alex/\n"},{"id":"73275","messageId":"b2cdc9f30803280852y4f160bb2tda1e688ddf7213e7@mail.gmail.com","threadId":"12900","inReplyTo":"32541b130803280550u2ed23b5auc84bf935d5344e84@mail.gmail.com","subject":"Re: Truncating and cleaning a imported git repositary to make it more usable","fromName":"Alex Bennee","fromEmail":"kernel-hacker@bennee.com","sentAt":"2008-03-28T15:52:21Z","receivedAt":"2008-03-28T15:52:21Z","isPatch":false,"sender":{"key":"kernel-hacker@bennee.com","avatar":null},"body":"On Fri, Mar 28, 2008 at 12:50 PM, Avery Pennarun wrote:\n> On 3/28/08, Alex Bennee wrote:\n> > 2. Create a new repo, starting at the common ancestor point\n> >\n> > 2(a). I'd need to remove the orphaned old CVS modules which are still\n> > around but not referenced any more.\n> >\n> > 3. Create the product branches and import ANCESTOR..BRANCH_HEAD into\n> > them\n>\n> You probably want to look at git-filter-branch, particularly the\n> --parent-filter option.\n>\n> Note that 2(a) would be easiest if you just did it before importing\n> from CVS at all, since it's easy to remove old modules from CVS just\n> by moving the files out of the way.\n\nAhh, having investigated further it seems the repo contains two CVS\nmodules which account for about 1/3 of the checkout and\nare not needed (as they are standalone and separate). When I do the\nfinal import from CVS I can skip them. Having said that I'll\nneed to run that over the weekend as cvsps takes up so much memory and\nswaps a lot.\n\nI tried what I think is the correct usage of git-filter-branch but I get:\n\najb@pitcairn:/export/git/fresh.git$ git-filter-branch --tree-filter\n'rm -rf big_dira big_dirb' dev-branch\nwarning: refname 'dev-branch' is ambiguous.\nWhich ref do you want to rewrite?\n\n\nAny ideas?\n\n-- \nAlex, homepage: http://www.bennee.com/~alex/\n"},{"id":"73276","messageId":"b2cdc9f30803280903w4a6e3a6l9e33fd188af9995a@mail.gmail.com","threadId":"12900","inReplyTo":"b2cdc9f30803280852y4f160bb2tda1e688ddf7213e7@mail.gmail.com","subject":"Re: Truncating and cleaning a imported git repositary to make it more usable","fromName":"Alex Bennee","fromEmail":"kernel-hacker@bennee.com","sentAt":"2008-03-28T16:03:18Z","receivedAt":"2008-03-28T16:03:18Z","isPatch":false,"sender":{"key":"kernel-hacker@bennee.com","avatar":null},"body":"On Fri, Mar 28, 2008 at 3:52 PM, Alex Bennee wrote:\n\n> ajb@pitcairn:/export/git/fresh.git$ git-filter-branch --tree-filter\n> 'rm -rf big_dira big_dirb' dev-branch\n> warning: refname 'dev-branch' is ambiguous.\n> Which ref do you want to rewrite?\n\nIgnore me. Not sure why but:\n\ngit-checkout dev-branch\ngit-filter-branch --tree-filter 'rm -rf big_dira big_dirb' HEAD\n\nworks\n\n\n-- \nAlex, homepage: http://www.bennee.com/~alex/\n"},{"id":"73281","messageId":"47ED204E.3020602@viscovery.net","threadId":"12900","inReplyTo":"b2cdc9f30803280903w4a6e3a6l9e33fd188af9995a@mail.gmail.com","subject":"Re: Truncating and cleaning a imported git repositary to make it more usable","fromName":"Johannes Sixt","fromEmail":"j.sixt@viscovery.net","sentAt":"2008-03-28T16:43:58Z","receivedAt":"2008-03-28T16:43:58Z","isPatch":false,"sender":{"key":"j6t@kdbg.org","avatar":"https://avatars.githubusercontent.com/u/14810926?v=4"},"body":"Alex Bennee schrieb:\n> On Fri, Mar 28, 2008 at 3:52 PM, Alex Bennee wrote:\n> \n>> ajb@pitcairn:/export/git/fresh.git$ git-filter-branch --tree-filter\n>> 'rm -rf big_dira big_dirb' dev-branch\n>> warning: refname 'dev-branch' is ambiguous.\n>> Which ref do you want to rewrite?\n> \n> Ignore me. Not sure why but:\n> \n> git-checkout dev-branch\n> git-filter-branch --tree-filter 'rm -rf big_dira big_dirb' HEAD\n\nYou really shouldn't do it this way, unless you do it on a ramdisk. Better\nuse an --index-filter. This is modeled after the last example in the man\npage (and, of course, untested):\n\ngit filter-branch --index-filter \\\n 'git ls-files -s |\n\t grep -v \"\tbig_dira\" |\n\t grep -v \"\tbig_dirb\" |\n GIT_INDEX_FILE=$GIT_INDEX_FILE.new \\\n git update-index --index-info &&\n mv $GIT_INDEX_FILE.new $GIT_INDEX_FILE' HEAD\n\nwhere the space before big_dir is actually a literal TAB!\n\n-- Hannes\n"},{"id":"73283","messageId":"1206727676.9819.22.camel@malory","threadId":"12900","inReplyTo":"47ED204E.3020602@viscovery.net","subject":"[PATCH] Documentation: Another example for git-filter-branch","fromName":"Alex Bennee","fromEmail":"kernel-hacker@bennee.com","sentAt":"2008-03-28T18:07:55Z","receivedAt":"2008-03-28T18:07:55Z","isPatch":true,"sender":{"key":"kernel-hacker@bennee.com","avatar":null},"body":"\nOn Fri, 2008-03-28 at 17:43 +0100, Johannes Sixt wrote:\n> Alex Bennee schrieb:\n> > git-checkout dev-branch\n> > git-filter-branch --tree-filter 'rm -rf big_dira big_dirb' HEAD\n> \n> You really shouldn't do it this way, unless you do it on a ramdisk. Better\n> use an --index-filter. This is modeled after the last example in the man\n> page (and, of course, untested):\n\nI missed the implications of the last example...\n\n> git filter-branch --index-filter \\\n> 'git ls-files -s |\n> \t grep -v \"\tbig_dira\" |\n> \t grep -v \"\tbig_dirb\" |\n> GIT_INDEX_FILE=$GIT_INDEX_FILE.new \\\n> git update-index --index-info &&\n> mv $GIT_INDEX_FILE.new $GIT_INDEX_FILE' HEAD\n> \n> where the space before big_dir is actually a literal TAB!\n\nGood example. Maybe we should add the following (because plenty of\nexamples is always a good thing IMHO)?\n\n>From 341b480bad4ed9f99a54dc66ba20b0cead4594b5 Mon Sep 17 00:00:00 2001\nFrom: Alex Bennee \nDate: Fri, 28 Mar 2008 18:00:20 +0000\nSubject: [PATCH] Update git filter-branch examples for cleaning directories\n\nI had to do this to a tree I imported from CVS which had a lot of cruft in it\nwhich was taking ages. Luckily Johannes Sixt submitted this scriplet on the list\nbefore I finished which makes things clearer.\n---\n Documentation/git-filter-branch.txt | 21 +++++++++++++++++++++\n 1 files changed, 21 insertions(+), 0 deletions(-)\n\ndiff --git a/Documentation/git-filter-branch.txt b/Documentation/git-filter-branch.txt\nindex 543a1cf..0e4b581 100644\n--- a/Documentation/git-filter-branch.txt\n+++ b/Documentation/git-filter-branch.txt\n@@ -184,6 +184,27 @@ git filter-branch --index-filter 'git update-index --remove filename' HEAD\n \n Now, you will get the rewritten history saved in HEAD.\n \n+If you need to remove whole directories it is tempting to use \"rm -rf\"\n+in the --tree-filter form, however this will generate a lot of disk IO\n+on big trees. Hence it's more preferable to use the index filter. For\n+example:\n+\n+--------------------------------------------------------------------------\n+git filter-branch --index-filter \\\n+ 'git ls-files -s |\n+ grep -v \" big_dira\" |\n+\tgrep -v \" big_dirb\" |\n+\t\tGIT_INDEX_FILE=$GIT_INDEX_FILE.new \\\n+ git update-index --index-info &&\n+\tmv $GIT_INDEX_FILE.new $GIT_INDEX_FILE' HEAD\n+--------------------------------------------------------------------------\n+\n+NB: The grep is matching literal TABs from the output of \"git\n+ls-files\". Try if your shell keeps giving you a directory\n+listing every time you hit tab.\n+\n+\n+\n To set a commit (which typically is at the tip of another\n history) to be the parent of the current initial commit, in\n order to paste the other history behind the current history:\n-- \n1.5.5.rc0.6.gdeda.dirty\n\n\n\n\n\n--\nAlex, homepage: http://www.bennee.com/~alex/\nWe reject: kings, presidents, and voting. We believe in: rough consensus\nand working code. -- Dave Clark\n"},{"id":"73284","messageId":"20080328180848.GA8299@coredump.intra.peff.net","threadId":"12900","inReplyTo":"b2cdc9f30803280903w4a6e3a6l9e33fd188af9995a@mail.gmail.com","subject":"Re: Truncating and cleaning a imported git repositary to make it more usable","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2008-03-28T18:08:49Z","receivedAt":"2008-03-28T18:08:49Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Fri, Mar 28, 2008 at 04:03:18PM +0000, Alex Bennee wrote:\n\n> > ajb@pitcairn:/export/git/fresh.git$ git-filter-branch --tree-filter\n> > 'rm -rf big_dira big_dirb' dev-branch\n> > warning: refname 'dev-branch' is ambiguous.\n> > Which ref do you want to rewrite?\n\nYou have two refs called dev-branch. Probably both a tag and a branch\n(i.e., refs/heads/dev-branch and refs/tags/dev-branch). You can\ndisambiguate by saying \"heads/dev-branch\").\n\n> Ignore me. Not sure why but:\n> \n> git-checkout dev-branch\n> git-filter-branch --tree-filter 'rm -rf big_dira big_dirb' HEAD\n\ngit-checkout prefers branches to tags[1], so there is no ambiguity. It\nputs the full refname (refs/heads/dev-branch) into your HEAD, so there\nis no ambiguity when saying \"HEAD\".\n\n[1] Actually, the upcoming builtin-checkout no longer behaves this way,\nand will complain about the ambiguity.\n\n-Peff\n"},{"id":"73286","messageId":"20080328181949.GC8299@coredump.intra.peff.net","threadId":"12900","inReplyTo":"20080328180848.GA8299@coredump.intra.peff.net","subject":"Re: Truncating and cleaning a imported git repositary to make it more usable","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2008-03-28T18:19:49Z","receivedAt":"2008-03-28T18:19:49Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Fri, Mar 28, 2008 at 02:08:49PM -0400, Jeff King wrote:\n\n> [1] Actually, the upcoming builtin-checkout no longer behaves this way,\n> and will complain about the ambiguity.\n\nTo clarify: it is simply a warning; it will still switch to the branch.\n\n-Peff\n"},{"id":"73288","messageId":"20080328204452.GA15737@glandium.org","threadId":"12900","inReplyTo":"47ED204E.3020602@viscovery.net","subject":"Re: Truncating and cleaning a imported git repositary to make it more usable","fromName":"Mike Hommey","fromEmail":"mh@glandium.org","sentAt":"2008-03-28T20:44:52Z","receivedAt":"2008-03-28T20:44:52Z","isPatch":false,"sender":{"key":"mh@glandium.org","avatar":"https://avatars.githubusercontent.com/u/1038527?v=4"},"body":"On Fri, Mar 28, 2008 at 05:43:58PM +0100, Johannes Sixt wrote:\n> Alex Bennee schrieb:\n> > On Fri, Mar 28, 2008 at 3:52 PM, Alex Bennee wrote:\n> > \n> >> ajb@pitcairn:/export/git/fresh.git$ git-filter-branch --tree-filter\n> >> 'rm -rf big_dira big_dirb' dev-branch\n> >> warning: refname 'dev-branch' is ambiguous.\n> >> Which ref do you want to rewrite?\n> > \n> > Ignore me. Not sure why but:\n> > \n> > git-checkout dev-branch\n> > git-filter-branch --tree-filter 'rm -rf big_dira big_dirb' HEAD\n> \n> You really shouldn't do it this way, unless you do it on a ramdisk. Better\n> use an --index-filter. This is modeled after the last example in the man\n> page (and, of course, untested):\n> \n> git filter-branch --index-filter \\\n> 'git ls-files -s |\n> \t grep -v \"\tbig_dira\" |\n> \t grep -v \"\tbig_dirb\" |\n> GIT_INDEX_FILE=$GIT_INDEX_FILE.new \\\n> git update-index --index-info &&\n> mv $GIT_INDEX_FILE.new $GIT_INDEX_FILE' HEAD\n\ngit filter-branch --index-filter 'git rm -r --cached big_dira big_dirb'\nshould be working nowadays.\n\nMike\n"},{"id":"73318","messageId":"b2cdc9f30803290647n31bd6db5r4f346360989c2dcd@mail.gmail.com","threadId":"12900","inReplyTo":"47ED204E.3020602@viscovery.net","subject":"Re: Truncating and cleaning a imported git repositary to make it more usable","fromName":"Alex Bennee","fromEmail":"kernel-hacker@bennee.com","sentAt":"2008-03-29T13:47:01Z","receivedAt":"2008-03-29T13:47:01Z","isPatch":false,"sender":{"key":"kernel-hacker@bennee.com","avatar":null},"body":"On Fri, Mar 28, 2008 at 4:43 PM, Johannes Sixt wrote:\n> Alex Bennee schrieb:\n> You really shouldn't do it this way, unless you do it on a ramdisk. Better\n> use an --index-filter. This is modeled after the last example in the man\n> page (and, of course, untested):\n>\n> git filter-branch --index-filter \\\n> 'git ls-files -s |\n> grep -v \" big_dira\" |\n> grep -v \" big_dirb\" |\n> GIT_INDEX_FILE=$GIT_INDEX_FILE.new \\\n> git update-index --index-info &&\n> mv $GIT_INDEX_FILE.new $GIT_INDEX_FILE' HEAD\n>\n> where the space before big_dir is actually a literal TAB!\n\nHmm thats odd. Despite having successfully run the filter my repo is\nstill the same size. git-fsck --full shows loads of dangling commits\nbut I'm guessing because the repo is packed they don't get dropped. Is\nit possible to repack the whole repo or do you have to manually unpack\nthe packs and re-pack?\n\n\n-- \nAlex, homepage: http://www.bennee.com/~alex/\n"},{"id":"73322","messageId":"fsljpe$i9o$1@ger.gmane.org","threadId":"12900","inReplyTo":"b2cdc9f30803290647n31bd6db5r4f346360989c2dcd@mail.gmail.com","subject":"Re: Truncating and cleaning a imported git repositary to make it more usable","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2008-03-29T14:30:08Z","receivedAt":"2008-03-29T14:30:08Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Alex Bennee wrote:\n\n> On Fri, Mar 28, 2008 at 4:43 PM, Johannes Sixt wrote:\n>> Alex Bennee schrieb:\n>>\n>> You really shouldn't do it this way, unless you do it on a ramdisk. Better\n>> use an --index-filter. This is modeled after the last example in the man\n>> page (and, of course, untested):\n>>\n>> git filter-branch --index-filter \\\n>> 'git ls-files -s |\n>> grep -v \" big_dira\" |\n>> grep -v \" big_dirb\" |\n>> GIT_INDEX_FILE=$GIT_INDEX_FILE.new \\\n>> git update-index --index-info &&\n>> mv $GIT_INDEX_FILE.new $GIT_INDEX_FILE' HEAD\n>>\n>> where the space before big_dir is actually a literal TAB!\n> \n> Hmm thats odd. Despite having successfully run the filter my repo is\n> still the same size. git-fsck --full shows loads of dangling commits\n> but I'm guessing because the repo is packed they don't get dropped. Is\n> it possible to repack the whole repo or do you have to manually unpack\n> the packs and re-pack?\n\nDid you pruned the repo (\"git gc --prune\" or \"git prune\")?\n-- \nJakub Narebski\nWarsaw, Poland\nShadeHawk on #git\n"},{"id":"73327","messageId":"47EE81BC.4020700@alum.mit.edu","threadId":"12900","inReplyTo":"1206707716.9819.15.camel@malory","subject":"Re: Truncating and cleaning a imported git repositary to make it more usable","fromName":"Michael Haggerty","fromEmail":"mhagger@alum.mit.edu","sentAt":"2008-03-29T17:51:56Z","receivedAt":"2008-03-29T17:51:56Z","isPatch":false,"sender":{"key":"mhagger@alum.mit.edu","avatar":"https://avatars.githubusercontent.com/u/119718?v=4"},"body":"Alex Bennee wrote:\n> I've succeeded in porting our whole CVS repository into git (with plenty\n> of swap, cvsps is very memory hungry). [...]\n\nIt sounds like you are doing a one-time conversion. If so, please\nconsider using cvs2svn [1], which can also convert to git [2].\ncvsps-based tools are known to have problems with most nontrivial CVS\nrepositories (the contents of the output repository simply don't agree\nwith those of the CVS original). IMO, the only reason to use a\ncvsps-based tool is if you really need incremental conversions *and* are\nwilling to live with data loss.\n\nBefore you trust your new repository, please make some checks. As a\nminimum, make sure that the contents of each tag and branch tip revision\nis the same as the contents that you get if you check out of CVS. (I\nbet they don't!)\n\nMichael\n\n[1] http://cvs2svn.tigris.org\n[2] http://cvs2svn.tigris.org/cvs2git.html\n"},{"id":"73410","messageId":"47F08202.9030206@viscovery.net","threadId":"12900","inReplyTo":"b2cdc9f30803290647n31bd6db5r4f346360989c2dcd@mail.gmail.com","subject":"Re: Truncating and cleaning a imported git repositary to make it more usable","fromName":"Johannes Sixt","fromEmail":"j.sixt@viscovery.net","sentAt":"2008-03-31T06:17:38Z","receivedAt":"2008-03-31T06:17:38Z","isPatch":false,"sender":{"key":"j6t@kdbg.org","avatar":"https://avatars.githubusercontent.com/u/14810926?v=4"},"body":"Alex Bennee schrieb:\n> Hmm thats odd. Despite having successfully run the filter my repo is\n> still the same size. git-fsck --full shows loads of dangling commits\n> but I'm guessing because the repo is packed they don't get dropped. Is\n> it possible to repack the whole repo or do you have to manually unpack\n> the packs and re-pack?\n\nYes. Run git repack -a -d -f or create a local clone using the file protocol:\n\n git clone file://$(pwd)/this that\n\n(If you don't use the file protocol, git clone just hard-links the\nrepository, and you again don't get the reduced size.)\n\n-- Hannes\n"}]}