* Subproject clones @ 2007-05-12 1:16 Amos Waterland 2007-05-12 1:26 ` Junio C Hamano 2007-05-12 8:05 ` Sven Verdoolaege 0 siblings, 2 replies; 4+ messages in thread From: Amos Waterland @ 2007-05-12 1:16 UTC (permalink / raw) To: git The logic in t3040-subprojects-basic.sh assumes that comparing the output of 'git-ls-files -s' when run in the original superproject and when run in the cloned superproject is a good test that cloning worked. However, the output of git-ls-files does not include the files in subprojects, so this test passes, even though the clone contains only the directories of the subprojects and none of their containing files or .git subdirectories. In other words, given this: superproject sub1 Makefile sub2 Makefile when somebody does `git-clone superproject', I believe they expect to get the same tree. Instead, they get this: superproject sub1 sub2 Note that `git-clone superproject/sub1` works as expected, but this sequence fails: git-clone superproject foo cd foo git-clone ../superproject/sub1 As does this sequence: git-clone superproject foo cd foo/sub1 git-pull ../superproject/sub1 So there is no way that I can see to actually clone a project that has subprojects. Is this intentional? Shouldn't clone get the entire superproject? ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: Subproject clones 2007-05-12 1:16 Subproject clones Amos Waterland @ 2007-05-12 1:26 ` Junio C Hamano 2007-05-12 1:32 ` Junio C Hamano 2007-05-12 8:05 ` Sven Verdoolaege 1 sibling, 1 reply; 4+ messages in thread From: Junio C Hamano @ 2007-05-12 1:26 UTC (permalink / raw) To: Amos Waterland; +Cc: git apw@us.ibm.com (Amos Waterland) writes: > Is this intentional? Shouldn't clone get the entire superproject? Yes. As 1.5.2 draft release notes and my response to somebody else last night mentioned, the plumbing level subproject support does _NOT_ recurse into subproject and this is deliberate. ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: Subproject clones 2007-05-12 1:26 ` Junio C Hamano @ 2007-05-12 1:32 ` Junio C Hamano 0 siblings, 0 replies; 4+ messages in thread From: Junio C Hamano @ 2007-05-12 1:32 UTC (permalink / raw) To: Amos Waterland; +Cc: git Junio C Hamano <junkio@cox.net> writes: > apw@us.ibm.com (Amos Waterland) writes: > >> Is this intentional? Shouldn't clone get the entire superproject? > > Yes. As 1.5.2 draft release notes and my response to somebody > else last night mentioned, the plumbing level subproject support > does _NOT_ recurse into subproject and this is deliberate. Namely: http://article.gmane.org/gmane.comp.version-control.git/46934 http://article.gmane.org/gmane.comp.version-control.git/46940 ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: Subproject clones 2007-05-12 1:16 Subproject clones Amos Waterland 2007-05-12 1:26 ` Junio C Hamano @ 2007-05-12 8:05 ` Sven Verdoolaege 1 sibling, 0 replies; 4+ messages in thread From: Sven Verdoolaege @ 2007-05-12 8:05 UTC (permalink / raw) To: Amos Waterland; +Cc: git On Fri, May 11, 2007 at 09:16:00PM -0400, Amos Waterland wrote: > In other words, given this: > > superproject > sub1 > Makefile > sub2 > Makefile > > when somebody does `git-clone superproject', I believe they expect to > get the same tree. Instead, they get this: I'm working on something like that. See the thread at http://article.gmane.org/gmane.comp.version-control.git/46163 I hope to send out an updated version later this weekend. skimo ^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2007-05-12 8:05 UTC | newest] Thread overview: 4+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2007-05-12 1:16 Subproject clones Amos Waterland 2007-05-12 1:26 ` Junio C Hamano 2007-05-12 1:32 ` Junio C Hamano 2007-05-12 8:05 ` Sven Verdoolaege
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).