* 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).