[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