{"thread":{"id":"8095","subject":"Subproject clones","startedAt":"2007-05-12T01:16:00Z","lastAt":"2007-05-12T08:05:15Z","messageCount":4,"participants":["Amos Waterland","Junio C Hamano","Sven Verdoolaege"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"41884","messageId":"20070512011600.GA24354@us.ibm.com","threadId":"8095","inReplyTo":null,"subject":"Subproject clones","fromName":"Amos Waterland","fromEmail":"apw@us.ibm.com","sentAt":"2007-05-12T01:16:00Z","receivedAt":"2007-05-12T01:16:00Z","isPatch":false,"sender":{"key":"apw@debian.org","avatar":null},"body":"The logic in t3040-subprojects-basic.sh assumes that comparing the\noutput of 'git-ls-files -s' when run in the original superproject and\nwhen run in the cloned superproject is a good test that cloning worked.\n\nHowever, the output of git-ls-files does not include the files in\nsubprojects, so this test passes, even though the clone contains only\nthe directories of the subprojects and none of their containing files \nor .git subdirectories.\n\nIn other words, given this:\n\n superproject\n  sub1\n   Makefile\n  sub2\n   Makefile\n\nwhen somebody does `git-clone superproject', I believe they expect to\nget the same tree.  Instead, they get this:\n\n superproject\n  sub1\n  sub2\n\nNote that `git-clone superproject/sub1` works as expected, but this\nsequence fails:\n\n git-clone superproject foo \n cd foo\n git-clone ../superproject/sub1\n\nAs does this sequence:\n\n git-clone superproject foo \n cd foo/sub1\n git-pull ../superproject/sub1\n\nSo there is no way that I can see to actually clone a project that has\nsubprojects.\n\nIs this intentional?  Shouldn't clone get the entire superproject?\n"},{"id":"41885","messageId":"7vr6pm7ry4.fsf@assigned-by-dhcp.cox.net","threadId":"8095","inReplyTo":"20070512011600.GA24354@us.ibm.com","subject":"Re: Subproject clones","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2007-05-12T01:26:27Z","receivedAt":"2007-05-12T01:26:27Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"apw@us.ibm.com (Amos Waterland) writes:\n\n> Is this intentional?  Shouldn't clone get the entire superproject?\n\nYes.  As 1.5.2 draft release notes and my response to somebody\nelse last night mentioned, the plumbing level subproject support\ndoes _NOT_ recurse into subproject and this is deliberate.\n"},{"id":"41886","messageId":"7vmz0a7rnq.fsf@assigned-by-dhcp.cox.net","threadId":"8095","inReplyTo":"7vr6pm7ry4.fsf@assigned-by-dhcp.cox.net","subject":"Re: Subproject clones","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2007-05-12T01:32:41Z","receivedAt":"2007-05-12T01:32:41Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Junio C Hamano <junkio@cox.net> writes:\n\n> apw@us.ibm.com (Amos Waterland) writes:\n>\n>> Is this intentional?  Shouldn't clone get the entire superproject?\n>\n> Yes.  As 1.5.2 draft release notes and my response to somebody\n> else last night mentioned, the plumbing level subproject support\n> does _NOT_ recurse into subproject and this is deliberate.\n\nNamely:\n\n    http://article.gmane.org/gmane.comp.version-control.git/46934\n    http://article.gmane.org/gmane.comp.version-control.git/46940\n"},{"id":"41904","messageId":"20070512080515.GH942MdfPADPa@greensroom.kotnet.org","threadId":"8095","inReplyTo":"20070512011600.GA24354@us.ibm.com","subject":"Re: Subproject clones","fromName":"Sven Verdoolaege","fromEmail":"skimo@kotnet.org","sentAt":"2007-05-12T08:05:15Z","receivedAt":"2007-05-12T08:05:15Z","isPatch":false,"sender":{"key":"skimo@kotnet.org","avatar":null},"body":"On Fri, May 11, 2007 at 09:16:00PM -0400, Amos Waterland wrote:\n> In other words, given this:\n> \n>  superproject\n>   sub1\n>    Makefile\n>   sub2\n>    Makefile\n> \n> when somebody does `git-clone superproject', I believe they expect to\n> get the same tree.  Instead, they get this:\n\nI'm working on something like that.\nSee the thread at\n\n\thttp://article.gmane.org/gmane.comp.version-control.git/46163\n\nI hope to send out an updated version later this weekend.\n\nskimo\n"}]}