{"thread":{"id":"19491","subject":"git subtree as a solution to partial cloning?","startedAt":"2009-05-25T07:35:38Z","lastAt":"2009-05-25T07:35:38Z","messageCount":1,"participants":["Asger Ottar Alstrup"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"114630","messageId":"8873ae500905250035h74fc366ct907998c62e518fcf@mail.gmail.com","threadId":"19491","inReplyTo":null,"subject":"git subtree as a solution to partial cloning?","fromName":"Asger Ottar Alstrup","fromEmail":"asger@area9.dk","sentAt":"2009-05-25T07:35:38Z","receivedAt":"2009-05-25T07:35:38Z","isPatch":false,"sender":{"key":"asger@area9.dk","avatar":null},"body":"I am considering different ways to get git to handle repositories with\nvery big files in a setup where partial clone is required, and it\nseems git subtree might be a part of the solution.\n\nDoes git subtree support splitting at the file level, or only at\ndirectory level? Also, how are conflicts handled when you subtree\nmerge changes back to the master? For this to work in practice, I\nsuppose the users of the split repositories should see the conflicts\nand fix them themselves. Can the reduced split repositories reuse pack\nfiles from the original repository? Can you think of any other\nlimitations to git subtree that would prevent it from working with big\nfiles to support a partial cloning setup?\n\nThe alternative seems to be git sparse checkout extended with\nnon-existing narrow clone, but it seems that a git subtree based\napproach might be simpler.\n\nRegards,\nAsger Ottar Alstrup\n"}]}