Re: [PATCH 07/16] git-read-tree: take --submodules option

From: Junio C Hamano <junkio@cox.net>
Date: May 24, 2007, 20:32 UTC
Message-ID: <7vy7jeufmn.fsf@assigned-by-dhcp.cox.net>
In-Reply-To: <20070524191438.GZ942MdfPADPa@greensroom.kotnet.org>

Sven Verdoolaege <skimo@kotnet.org> writes:

[side note: I am ignoring your reply-to: liacs.nl as its MTA seems to use sorbs that has my ISP's outgoing sender identified as spam source; I'll send the bounce to you privately in a separate message.]

Show 21 quoted lines

> On Thu, May 24, 2007 at 11:58:26AM -0700, Junio C Hamano wrote:
>> Sven Verdoolaege <skimo@kotnet.org> writes:
>> > On Thu, May 24, 2007 at 11:26:01AM -0700, Junio C Hamano wrote:
>> >>  (2) In superproject .git/, we would have a bare repository for
>> >>      each project used by the superproject.
>> >> 
>> >> 	.git/subproject/kernel26/{objects,refs,...}
>> >> 
>> >>      This is created by making a bare clone from the upstream
>> >>      URL, decided by the user with the help from suggested URL
>> >>      described in the superproject .gitmodules.
>> >
>> > Do you mean a "pure" clone, i.e., without a working tree,
>> > but with separate-remotes?
>> 
>> I meant a bare clone without separate remotes.
>
> Why without separate remotes?
> It has been argued before that changes in the subproject
> may come from different remotes, so the user may want
> to configure extra remotes from which to fetch.

By different remotes, which do you mean?

 (1) .git/subprojects/kernel26/ repository has 'origin'
     different from any of the suggested URL in .gitmodules, but
     as far as it is concerned there is one 'origin';

or

 (2) it has 'origin' that is what the superproject suggests, but
     the user locally uses additional repositories to pull and
     merge from;

If the former that is not an argument, so I'd assume the latter. I would say in such a case, you are better off having a usual repository to manage the development of subproject part, not grafted to any superproject repository, and handle such merges there (after all, a "subproject" should stand on its own without having any of the superproject stuff). And treat THAT repository as the 'origin' used in (1) above. It might be easier to use non separate-remote layout in the standalone repository for the subproject, but that is a separate issue.

Show 8 quoted lines

>> The counter-proposal outline essentially says, for the sake of
>> simplicity, "nuke existing subproject directory whenever we need
>> to replace it with something else, and reclone a new/replacement
>> subproject directory every time we need to check it out, after
>> making sure nothing is lost".
>
> And she can't do it in the clone in his working tree if that's
> going to get nuked from time to time.

And she does not have to. She can do the development/fixes in (temporarily) checked out subproject tree, and push it back to the .git/subproject/kernel26/ repository in the superproject before she leaves (i.e. before branch switching at superproject level needs to obliterate it). The change stored in the .git/subproject/kernel26/ repository in the superproject can further be pushed back to its 'origin', be it the true "upstream", or "the standalone repository for the subproject" I mentioned above.

> But you still need figure out _what_ to fetch.
> Before you suggested to just use the default set up by
> clone with separate remotes, but you no longer have that
> in your new proposal.

I do remember saying the "default set up by clone" but I did not mean separate remotes.

What is fetched by a bare and non-separate-remote repository vs a repository that uses separate-remote layout from 'origin' is exactly the same -- the difference is only 'pure/bare' layout would use

	fetch = refs/heads/*:refs/heads/*

while separate-remotes would use

	fetch = refs/heads/*:/refs/remotes/origin/*

So I do not think the difference matters for our purpose of being able to check out commits that are referenced in superproject trees. As long as we require that the 'origin' for "longer term repository to keep track of the subproject in superproject" (aka repository (2) in my message you are responding to) always contain the commit referenced by tree objects in the superproject, which I think is a sensible thing to require (otherwise you cannot even clone and checkout the whole superproject), both layout would work equally well. It's just bare/pure layout is easier to understand because it is essentially a "mirror" of the upstream.