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

[Martin Geisler]

Matt Mackall <mpm at selenic.com> writes:

> 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.

That is already the case today: as you know, the .hgsub file is not
synchronized with the sub/.hg/hgrc file in any way, and so 'hg pull' in
the subrepository can do very different things compared to the pull
triggered by 'hg update' in the outer repository.

So I think the consistency you are trying to achieve is not there in the
first place.

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

I think it has some value to make

  $ hg clone /foo/bar

behave more like

  $ hg init bar
  $ cd bar
  $ hg pull --update /foo/bar

-- 
Martin Geisler

Mercurial links: http://mercurial.ch/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL: <http://selenic.com/pipermail/mercurial-devel/attachments/20110325/57a0701a/attachment.pgp>