<br><br><div class="gmail_quote">On Fri, Mar 25, 2011 at 5:45 PM, Matt Mackall <span dir="ltr"><<a href="mailto:mpm@selenic.com">mpm@selenic.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="im">On Fri, 2011-03-25 at 17:27 +0100, Martin Geisler wrote:<br>
> Matt Mackall <<a href="mailto:mpm@selenic.com">mpm@selenic.com</a>> writes:<br>
><br>
> > On Fri, 2011-03-25 at 16:07 +0100, Martin Geisler wrote:<br>
> >> # HG changeset patch<br>
> >> # User Martin Geisler <<a href="mailto:mg@aragost.com">mg@aragost.com</a>><br>
> >> # Date 1300989966 -3600<br>
> >> # Node ID a8019f68e1463d6b1d5406f5f22d17f9aa8c828c<br>
> >> # Parent e45780ac829283080ad6b5a5e064e59a163c08d6<br>
> >> subrepo: look for local pull source first<br>
> >><br>
> >> With this change, a subrepository will always try to find the<br>
> >> changesets it needs in a repository relative to the pull source of the<br>
> >> top-most parent repository. So if we have<br>
> >><br>
> >> repo/<br>
> >> sub/<br>
> >><br>
> >> and make a clone with 'hg clone repo clone', then clone/sub will pull<br>
> >> in changesets from repo/sub, regardless of what the .hgsub file says.<br>
> ><br>
> > There's a lot that's weird with this.<br>
> ><br>
> > Consider how completely different the behavior will be if you manually<br>
> > run hg pull in a subrepo vs having the subrepo code do it for you. I<br>
> > think this issue by itself is a show-stopper.<br>
><br>
> It is not really different from what happens today if you do<br>
><br>
> $ hg pull --update /foo<br>
<br>
</div>Show is still stopped. Address the point I raised, pleased. It makes<br>
absolutely no sense for a manual pull in a subrepo directory to do<br>
something completely different BY DEFAULT than what an automatic pull of<br>
the same repo via the subrepo code would do BY DEFAULT. That can only<br>
cause problems.<br>
<br>
Pull --update <some arg> is a completely different beast that is<br>
explicitly overriding the defaults.<br>
<div class="im"><br>
--<br>
Mathematics is the supreme nostalgia of our time.<br>
<br>
<br>
_______________________________________________<br>
</div><div><div></div><div class="h5">Mercurial-devel mailing list<br>
<a href="mailto:Mercurial-devel@selenic.com">Mercurial-devel@selenic.com</a><br>
<a href="http://selenic.com/mailman/listinfo/mercurial-devel" target="_blank">http://selenic.com/mailman/listinfo/mercurial-devel</a><br>
</div></div></blockquote></div><br>Matt,<br><br>you are right that this does not make much sense but it is actually exactly what happens today!<br><br>When I started using suprepos the most surprising thing for me was that the pull source for the subrepos was not the default pull source specified in the subrepo .hgrc file, but instead that it was set in stone in the .hgsub file.<br>
<br>The result of this (weird, IMHO) design is that as you just said pulling from within a subrepo my use a completely different source that would be use when pulling that same subrepository through a pull operation on its parent repository! This is I think a big gotcha of the current suprepo implementation.<br>
<br>I always wondered why isn't it possible have an .hgsub file in which no pull source is set. In that case mercurial could do what Martin is suggesting, i.e. use the subrepo default pull source.<br><br>Angel<br><br>
<br>