# Subproject clones

4 messages from 2007-05-12 to 2007-05-12. Participants: Amos Waterland, Junio C Hamano, Sven Verdoolaege.
Thread: https://gitlist.dev/t/8095

## Amos Waterland, 2007-05-12 01:16

Subject: Subproject clones
Message-ID: <20070512011600.GA24354@us.ibm.com>
URL: https://gitlist.dev/e/20070512011600.GA24354%40us.ibm.com

```
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?

```

## Junio C Hamano, 2007-05-12 01:26

Subject: Re: Subproject clones
Message-ID: <7vr6pm7ry4.fsf@assigned-by-dhcp.cox.net>
URL: https://gitlist.dev/e/7vr6pm7ry4.fsf%40assigned-by-dhcp.cox.net
In-Reply-To: <20070512011600.GA24354@us.ibm.com>

```
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.

```

## Junio C Hamano, 2007-05-12 01:32

Subject: Re: Subproject clones
Message-ID: <7vmz0a7rnq.fsf@assigned-by-dhcp.cox.net>
URL: https://gitlist.dev/e/7vmz0a7rnq.fsf%40assigned-by-dhcp.cox.net
In-Reply-To: <7vr6pm7ry4.fsf@assigned-by-dhcp.cox.net>

```
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

```

## Sven Verdoolaege, 2007-05-12 08:05

Subject: Re: Subproject clones
Message-ID: <20070512080515.GH942MdfPADPa@greensroom.kotnet.org>
URL: https://gitlist.dev/e/20070512080515.GH942MdfPADPa%40greensroom.kotnet.org
In-Reply-To: <20070512011600.GA24354@us.ibm.com>

```
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

```