{"thread":{"id":"15239","subject":"Splitting off old history to ancillary repo","startedAt":"2008-08-28T02:40:23Z","lastAt":"2008-08-28T16:57:57Z","messageCount":2,"participants":["Martin Langhoff","Michael J Gruber"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"88859","messageId":"46a038f90808271940w3aaf5c4ek6329e8066724c778@mail.gmail.com","threadId":"15239","inReplyTo":null,"subject":"Splitting off old history to ancillary repo","fromName":"Martin Langhoff","fromEmail":"martin.langhoff@gmail.com","sentAt":"2008-08-28T02:40:23Z","receivedAt":"2008-08-28T02:40:23Z","isPatch":false,"sender":{"key":"martin.langhoff@gmail.com","avatar":"https://gravatar.com/avatar/1e3f311b6c4c15836501901ca58f8c0b0667246488084ba524d8bc9867e22fd9?d=mp&s=160"},"body":"A project I've inherited has a codebase ~500KB in size. However, in\nearly history some large binary blobs were committed to the repo.\nWe've gotten rid of those, and they are not interesting to current\ndevelopment. But an initial checkout still has to retrieve 60MiB, when\nI'm sure the recent (and interesting) history fits in less than 1MB.\n\nWhat is the state of grafts from a \"keeping the repo mostly\ntransparently usable for newcomers\" POV? Is there a new mechanims I\nshould look at?\n\nDo we have a documented \"here's how you split your repo with minimal\ndownsides to end users\"? If you give me enough hints I could write it\n:-)\n\nThe repo in question is http://dev.laptop.org/git?p=projects/xs-config;a=summary\n\ncheers,\n\n\nm\n-- \n martin.langhoff@gmail.com\n martin@laptop.org -- School Server Architect\n - ask interesting questions\n - don't get distracted with shiny stuff - working code first\n - http://wiki.laptop.org/go/User:Martinlanghoff\n"},{"id":"88916","messageId":"48B6D915.8080706@fastmail.fm","threadId":"15239","inReplyTo":"46a038f90808271940w3aaf5c4ek6329e8066724c778@mail.gmail.com","subject":"Re: Splitting off old history to ancillary repo","fromName":"Michael J Gruber","fromEmail":"michaeljgruber+gmane@fastmail.fm","sentAt":"2008-08-28T16:57:57Z","receivedAt":"2008-08-28T16:57:57Z","isPatch":false,"sender":{"key":"git@grubix.eu","avatar":"https://avatars.githubusercontent.com/u/233215?v=4"},"body":"Martin Langhoff venit, vidit, dixit 28.08.2008 04:40:\n> A project I've inherited has a codebase ~500KB in size. However, in\n> early history some large binary blobs were committed to the repo.\n> We've gotten rid of those, and they are not interesting to current\n> development. But an initial checkout still has to retrieve 60MiB, when\n> I'm sure the recent (and interesting) history fits in less than 1MB.\n> \n> What is the state of grafts from a \"keeping the repo mostly\n> transparently usable for newcomers\" POV? Is there a new mechanims I\n> should look at?\n\nDo you mean newcomers who have never cloned your repo before?\n\nI see two ways, both involving history rewriting (and therefore problems\nfor people who cloned already):\n\n- remove those files using filter-branch\nThis keeps the whole history in one repo but can produce empty commits\n(which touched only the removed files).\n\n- split the history using grafts and use filter-branch to make the split\nfor good\nThis gives you a split history which you can now put in different repos.\nPeople interested in the full history can pull both and connect the\nhistory using grafts.\n\nI've used both (depending on the use case), both work well.\n\nMichael\n"}]}