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

[Matt Mackall]

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.


-- 
Mathematics is the supreme nostalgia of our time.