[PATCH 1 of 2] subrepo: look for local pull source first

[Matt Mackall]

On Fri, 2011-03-25 at 17:27 +0100, Martin Geisler wrote:
> Matt Mackall <mpm at selenic.com> writes:
> 
> > On Fri, 2011-03-25 at 16:07 +0100, Martin Geisler wrote:
> >> # HG changeset patch
> >> # User Martin Geisler <mg at aragost.com>
> >> # Date 1300989966 -3600
> >> # Node ID a8019f68e1463d6b1d5406f5f22d17f9aa8c828c
> >> # Parent  e45780ac829283080ad6b5a5e064e59a163c08d6
> >> subrepo: look for local pull source first
> >> 
> >> With this change, a subrepository will always try to find the
> >> changesets it needs in a repository relative to the pull source of the
> >> top-most parent repository. So if we have
> >> 
> >>   repo/
> >>     sub/
> >> 
> >> and make a clone with 'hg clone repo clone', then clone/sub will pull
> >> in changesets from repo/sub, regardless of what the .hgsub file says.
> >
> > There's a lot that's weird with this.
> >
> > Consider how completely different the behavior will be if you manually
> > run hg pull in a subrepo vs having the subrepo code do it for you. I
> > think this issue by itself is a show-stopper.
> 
> It is not really different from what happens today if you do
> 
>   $ hg pull --update /foo

Show is still stopped. Address the point I raised, pleased. It makes
absolutely no sense for a manual pull in a subrepo directory to do
something completely different BY DEFAULT than what an automatic pull of
the same repo via the subrepo code would do BY DEFAULT. That can only
cause problems. 

Pull --update <some arg> is a completely different beast that is
explicitly overriding the defaults.

-- 
Mathematics is the supreme nostalgia of our time.