[PATCH] status: add option to show status of files in subrepos

[Steve Borho]

On Thu, Jul 8, 2010 at 12:42 PM, Matt Mackall <mpm at selenic.com> wrote:
> On Thu, 2010-07-08 at 18:14 +0200, Didly wrote:
>>
>>
>> On Thu, Jul 8, 2010 at 5:20 PM, Steve Losh <steve at stevelosh.com>
>> wrote:
>>
>>         > Matt,
>>         >
>>         >
>>         > Thank you for trying to explain this to me. I think that I
>>         > understand what you are saying. However, what I do not
>>         > understand is the following:
>>         >
>>         >
>>         > - Assume that the user has cloned a repository that contains
>>         > several subrepos.
>>         > - The user has then used "hg update" at least once, to
>>         >  select a revision to which its working copy will point to.
>>         >
>>         >
>>         > At this point, there is one and only one "current" .hgsub
>>         > file. This file contains the list of the subrepositories
>>         > that are referenced by the current revision of repository
>>         > and to which folders they correspond to. It also says their
>>         > corresponding "pull sources" (for lack of a better name).
>>         >
>>         >
>>         > Now, if the user executed "hg pull", wouldn't mercurial have
>>         > all the information that it needs to perform the pull on all
>>         > the subrepositories that are defined for the current
>>         > revision of the top repository?
>>
>>
>>         It should never need to pull at this point.
>>
>>
>>         When you run 'hg update REV' Mercurial clones/updates the
>>         subrepos to the revisions specified in the .hgsubstate file in
>>         REV.
>>
>>
>>         When you run "hg pull" after that the .hgsubstate isn't
>>         touched (unless you're using "-u", but that's beside the
>>         point), so the revisions listed for each subrepo haven't
>>         changed, so it doesn't need to pull.
>>
>> Steve, thanks for the explanation.
>>
>> I was confused because according to Matt's explanation I thought that
>> he implied that "pull" _cannot_ be recursive. Yet, it seems that you
>> guys are saying that "pull" _could_ be recursive, but it does not
>> _need_ to be. Is that correct?
>
> No, it cannot be recursive. Or at least no one has yet been able to
> articulate a fully thought-out approach.
>
> Again: there may be multiple heads. These different heads may point to
> -entirely different- sets of subrepos to pull. Further, none of these
> may have corresponding directories in the current working directory.
>
> So again:
>
> a) we don't know WHAT subrepos to pull at pull time
> b) we don't know WHERE to put them if we did
>
> And there's also:
>
> c) with some repo types, don't have a pull operation anyway
>
> But really, it doesn't matter much. Update recursively pulls subrepos if
> needed, so the only time you get into trouble is when repos are
> available at pull time and not available at update time.

I think Angel is asking is for an option like:

hg pull --recursive

that pulls revisions into the local repo, then pulls all mercurial
subrepos that are checked out in the working revision.

--recursive would have to exclude options like --update and --rebase
to have any meaning.  But I can see it being very useful to a lot of
work flows.

-- 
Steve Borho