On Sat, May 19, 2007 at 11:20:12 -0700, Junio C Hamano wrote:
> Sven Verdoolaege <skimo@xxxxxxxxxx> writes:
>
> > Does everyone agree that we should fetch (possibly after asking
> > for confirmation from the use) _during_ the checkout ?
> > I now only fetch submodules during a fetch of the supermodule
> > (actually, in my current patch set, I only fetch a submodule
> > the first time I see it, but that's a bug), but if there is
> > a consensus on this, I can switch to fetching during checkout.
>
> I think fetching of subproject during fetch or clone of
> superproject would not make much sense. Making it part of
> superproject checkout would probably be the way we will end up
> going. The detail of "which part of the checkout" would need to
> be defined, and I tend to agree with Alex that checkout itself
> would need to be multi-phased, but I think that is a minor
> implementation detail we can discuss after how the overall flows
> should look like.
IMHO it makes more sense to fetch during fetch of superproject:
- If you don't fetch the superproject, it won't start refering to
unavailable commit of subproject. So should only need to fetch subproject
after fetching superproject.
- If you fetch from more than one location, you want to fetch subproject
from location corresponding to where you fetch superproject from.
Let's have a repository of project P with remotes PA and PB. Let it have
a subproject S with remotes SA and SB.
Whenever I pull P from PA, it might refer to commit of S, that is only
available from SA (because that's what PA owner uses). Whenever I pull
P from PB, it might refer to commit of S, that is only available from SB
(again because that's what PB owner uses).
Now checkout does not know, whether I pulled the target revision from PA
or PB, so:
- Either it has to fetch both. But say the commit I want is in SB and SA
contains a lot of new stuff, which will slow the thing down, though
I don't need it.
- Or it has to guess by looking whether any heads in remotes/PA or
remotes/PB are descendants of the commit being checked out. But that
feels rather hacky.
I see several options:
- Fetch will recurse. This should work ok and is IMHO least magic. We can
also add some way to specify refspecs for the subproject, giving user
control over what is fetched.
- Fetch will store a "pending fetch from" note in the subproject and
checkout, if it does not find the revision, will try fetching from all
sources pointed to by those notes. There is still a problem with what
exactly to fetch (user can specify in config).
- Checkout will ask all subproject repositories whether they have given
commit and pull the first one that does. This would get the needed
commit most certainly. It would be slower though, because it would need
to ask all the repositories whether they have the particular object.
It also leaves the tracking branches in subproject in somewhat random
state (maybe both repositories had the commit, so it pulled from the
other one that user would etc.).
> > As to the key to use to lookup the URL in the config, right
> > now I simply use the directory name where it is attached
> > (which seems like a useful default to me).
The extra level of indirection has the advantage, that you can describe
moving the same subproject to a different directory.
--
Jan 'Bulb' Hudec <bulb@xxxxxx>
Attachment:
signature.asc
Description: Digital signature
