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

[Didly]

On Thu, Jul 8, 2010 at 7:54 PM, Steve Borho <steve at borho.org> wrote:

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

Yes, that is exactly what I am asking for :-)

I'd like to be able to pull all subrepos which are present in the _current_
working revision. In that context it does not matter that there may be other
revisions in which some of the current subrepos may not be present, or on
different locations or whatever.

It would be ok if Mercurial complained (with a warning for instance) if one
or more subrepos are of a type that does not support pull.

Angel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://selenic.com/pipermail/mercurial-devel/attachments/20100708/37ec5629/attachment.htm>