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.
> 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.
> If we were to follow the outline in the counter-proposal, I'd
> imagine that update of (2) can happen at any time. It could be
> part of "git fetch" in superprojects, of lazily done when we
> need to checkout a new revision for a particular subproject, but
> only if the last time you fetched superproject is more recent
> than the time you updated (2) for the subproject last time.
>
> Or something like that. I consider that also a minor detail in
> the implementation.
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.
skimo
-
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
