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

Didly Bom didlybom at gmail.com
Thu Jul 8 08:24:56 CDT 2010


On Thu, Jul 8, 2010 at 3:11 PM, Martin Geisler <mg at aragost.com> wrote:

> Matt Mackall <mpm at selenic.com> writes:
>
> > When you submit a change like this, please show us what it looks like
> > so we can talk about it. One of the common complaints about subrepos
> > is that it's not obvious when a subrepo is modified so commit's
> > recursive behavior bites people. So it's not clear that:
> >
> > M foo
> > M sub/bar
> >
> > really gives people enough notice that it's a subrepo that's changed.
> > But then:
> >
> > M foo
> > M subrepo/
> >
> > is just weird, so maybe your way is right after all. Opinions?
>
> I don't think it's that weird -- it has the advantage that you can
> distinguish between a file changed in a subdirectory and a changed
> subrepository.
>
> Subversion simply reports X for all svn:externals and then reports their
> status afterwards. It looks like this:
>
>  % svn status
>  X       ext
>
>  Performing status on external item at 'ext'
>  M       ext/a.txt
>

So in mercurial's case what you propose it for mercurial to report:

% hg status
S       ext

Performing status on subrepository 'ext'
M       ext/a.txt

Is that it? If so it seems a good solution to me.



> > Is there a reason not to have a -S flag?
>
> Should this only be enabled with a flag? I think that when 'hg commit'
> will recurse by default, then 'hg status' should do the same. Or would
> you rather that people add
>
>  [defaults]
>  status = --subrepos
>  diff = --subrepos
>  ...
>
> to their hgrc files? If we require this, then my feeling is that
> subrepositories will never become a first-class feature. However,
> Telling people to not use subrepositories until their frontends have
> caught up is also not nice.
>

I completely agree in that the interface must be consistent. If commit
recurses down to the subrepos by default, then status should recurse too.

I personally like the fact that subrepos are "transparent" in the sense that
operations on the top repository are recursive down to subrepos.

What about hg pull/push? As far as I know pull and push do not currently
work recursively, do they?

 Since we can have different types of subrepositories, I wonder how to
> best combine the status output of each. Subversions output looks a
> little different from ours -- like us, they have room to indicate a
> change in the file but they also have room to indicate a change in a
> property.
>

I don't know if making all commands recursive by default that is the best
approach for all types of external subrespositorires. That being said, I
think that but for the mercurial-based subrepos it definitely is the best
way to go (IMHO). Thus, I'd rather have a flag that could be used to tell hg
to work on the top repository alone (i.e. to not recurse down to the
subrepos).

Cheers,

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


More information about the Mercurial-devel mailing list