Sven Verdoolaege <skimo@xxxxxxxxxx> 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.]
> On Thu, May 24, 2007 at 11:58:26AM -0700, Junio C Hamano wrote:
>> Sven Verdoolaege <skimo@xxxxxxxxxx> 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.
>> 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.
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
