Dealing consistently with subrepositories

Martin Geisler mg at aragost.com
Wed Mar 30 03:16:51 CDT 2011


Mads Kiilerich <mads at kiilerich.com> writes:

> Martin Geisler wrote, On 03/29/2011 03:07 PM:
>> It feels wrong to me that incoming supports recursion when pull does
>> not. Perhaps pull should support --subrepos too and then just do what
>> incoming does, namely do 'hg pull' in each subrepo. (There is nothing
>> inconsistent about this, the next 'hg update' will still give you a
>> consistent state.)
>
> I think it would be better to forget about incoming --subrepos.
>
> Incoming without --subrepos will show the top level revisions. Each
> revision might include references to new subrepo revisions, but only
> these subrepo revisions are reachable. Other subrepo revisions are
> really not interesting for regular use of subrepos.

Yes, I see what you are saying -- you will only be checking out the
changesets mentioned in .hgsubstate files (recursively). Mostly... :-)
With that argument you could also argue that 'hg incoming' should just
show the remote tip since that is where you will go after 'hg pull' and
'hg update'.

But we don't do that and I like to see all the little steps (changesets)
that are part of the pull. I expect people to feel the same about
subrepos: if a pull in the libfoo will bring in 10 new changesets, then
I want to know about all 10 steps.

I imagine that 'hg pull --subrepos' would do 'hg pull' in each subrepo
so you get what you are *likely* to need on the next update.

> Subrepos abstracts the details and intermediate revisions away and
> only looks at the referenced revisions. (onsub incoming and onsub pull
> is a different story.)
>
> This reasoning gets close to a discussion on whether revision
> specifications and log should be recursive too. I wonder why you
> havent mentioned that aspect yet ;-)

Oh, yeah, that command :) I don't have all the answers here so let me
know what you think about log... where does it belong?

Personally I think it would be weird to have a recursive log since I
cannot imagine how to output the entries in a usable order. The log
command is already only usable with --limit or with a pager which just
implicitly limits the output. But with 5-10 subrepos you get a lot of
changesets when you do

  $ hg log -l 2

and I don't see the sense of that.

-- 
Martin Geisler

aragost Trifork
Professional Mercurial support
http://aragost.com/en/services/mercurial/blog/


More information about the Mercurial-devel mailing list