{"thread":{"id":"4506","subject":"'sparse' clone idea","startedAt":"2006-06-14T08:23:54Z","lastAt":"2006-06-14T09:44:41Z","messageCount":3,"participants":["Jakub Narebski","Johannes Schindelin"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"21771","messageId":"e6oh2g$ngh$1@sea.gmane.org","threadId":"4506","inReplyTo":null,"subject":"'sparse' clone idea","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2006-06-14T08:23:54Z","receivedAt":"2006-06-14T08:23:54Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"I wonder if 'sparse clone' idea described below would avoid the most\ndifficult part of 'shallow clone' idea, namely the [sometimes] need to\nun-cauterize history. See: (<7vac8lidwi.fsf@assigned-by-dhcp.cox.net>).\n\n'sparse clone' begins like 'shallow clone': full history is copied down to\nspecified point of history (cut-off or cauterization point for shallow\nclone), but instead of cauterizing the history from that point downwards,\nthe history is simplified using grafts.\n\nIn the sparse part we need:\n * all commits pointed by tags (if we clone/copy tags) \n   and other refs (if we clone/copy those tags)\n * merge bases for all commits in full, and in the sparse part,\n   _including_ merge bases themselves\n * all roots\n\nCommits in sparse part would be connected like in original history, only\nskipping \"uniteresting\" commits.\n\n\nThoughts? Comments?\n\n-- \nJakub Narebski\nWarsaw, Poland\nShadeHawk on #git\n"},{"id":"21774","messageId":"Pine.LNX.4.63.0606141110001.15673@wbgn013.biozentrum.uni-wuerzburg.de","threadId":"4506","inReplyTo":"e6oh2g$ngh$1@sea.gmane.org","subject":"Re: 'sparse' clone idea","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2006-06-14T09:20:49Z","receivedAt":"2006-06-14T09:20:49Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Wed, 14 Jun 2006, Jakub Narebski wrote:\n\n> I wonder if 'sparse clone' idea described below would avoid the most\n> difficult part of 'shallow clone' idea, namely the [sometimes] need to\n> un-cauterize history. See: (<7vac8lidwi.fsf@assigned-by-dhcp.cox.net>).\n\nI do not think that is the hardest problem. The hardest thing is to tell \nthe server in an efficient manner which objects we have.\n\nExample:\n\nA - B - C - D\n    ^ cutoff\n        ^ current HEAD\n\nSuppose B is your fake root, C is your HEAD, you want to fetch D. Now, \nmake it a difficult example: both A and D contain a certain blob Z, but \nneither B nor C do. You have to tell the server _in an efficient manner_ \nto send Z also.\n\nAnd by efficient manner I mean: you may not bring the server down just \nbecause 5 people with shallow clones decide to fetch from it.\n\n> 'sparse clone' begins like 'shallow clone': full history is copied down to\n> specified point of history (cut-off or cauterization point for shallow\n> clone), but instead of cauterizing the history from that point downwards,\n> the history is simplified using grafts.\n> \n> In the sparse part we need:\n>  * all commits pointed by tags (if we clone/copy tags) \n>    and other refs (if we clone/copy those tags)\n>  * merge bases for all commits in full, and in the sparse part,\n>    _including_ merge bases themselves\n\nHmmm. You cannot know _all_ merge bases beforehand, because you do not \ndecide where other people fork off.\n\n>  * all roots\n\nWhy?\n\n> Commits in sparse part would be connected like in original history, only\n> skipping \"uniteresting\" commits.\n\nInteresting idea, though I do not think it solves the most pressing \nproblems we have with shallow clones.\n\nCiao,\nDscho\n\nP.S.: I think the problems of a lazy clone are much easier to solve...\n"},{"id":"21777","messageId":"e6olpv$77s$1@sea.gmane.org","threadId":"4506","inReplyTo":"Pine.LNX.4.63.0606141110001.15673@wbgn013.biozentrum.uni-wuerzburg.de","subject":"Re: 'sparse' clone idea","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2006-06-14T09:44:41Z","receivedAt":"2006-06-14T09:44:41Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Johannes Schindelin wrote:\n\n> On Wed, 14 Jun 2006, Jakub Narebski wrote:\n> \n>> I wonder if 'sparse clone' idea described below would avoid the most\n>> difficult part of 'shallow clone' idea, namely the [sometimes] need to\n>> un-cauterize history. See: (<7vac8lidwi.fsf@assigned-by-dhcp.cox.net>).\n> \n> I do not think that is the hardest problem. The hardest thing is to tell \n> the server in an efficient manner which objects we have.\n> \n> Example:\n> \n> A - B - C - D\n>     ^ cutoff\n>         ^ current HEAD\n> \n> Suppose B is your fake root, C is your HEAD, you want to fetch D. Now, \n> make it a difficult example: both A and D contain a certain blob Z, but \n> neither B nor C do. You have to tell the server _in an efficient manner_ \n> to send Z also.\n> \n> And by efficient manner I mean: you may not bring the server down just \n> because 5 people with shallow clones decide to fetch from it.\n\nNah, that I think is solved. Check the mentioned post by Junio C Hamano\nin the \"Re: Figured out how to get Mozilla into git\" post:\n\n http://permalink.gmane.org/gmane.comp.version-control.git/21603\n\n(although it would need extension to the git protocol). Client and server \ndo graft exchange both ways, limiting the commit ancestry graph the both\nends walk to the intersection of the fake view of the ancestry graph both\nends have. Then server uses those virtual grafts to calculate which objects\nto send.\n\nThe rest is done (or should be done) by history grafting code.\n\n>>  * merge bases for all commits in full, and in the sparse part,\n>>    _including_ merge bases themselves\n> \n> Hmmm. You cannot know _all_ merge bases beforehand, because you do not \n> decide where other people fork off.\n\nBy all merge bases I mean merge bases for all commits in full part, merge\nbases for all commits in full part and commits pointed by tags in sparse\npart, merge bases for all commits in full part and tagged in sparse part\nand merge bases in sparse part etc. recursively.\n \n>>  * all roots\n> \n> Why?\n\nJust in case, as an ultimate merge bases.\n \n> P.S.: I think the problems of a lazy clone are much easier to solve...\n\nI still think that the correct idea for the lazy clone is to have soft\ngrafts, so you have to solve at least part of shallo clone/sparse clone\nproblems first.\n\n-- \nJakub Narebski\nWarsaw, Poland\nShadeHawk on #git\n"}]}