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

[David Mitchell]

On Sat, Jun 12, 2010 at 12:12 AM, Didly Bom <didlybom at gmail.com> wrote:

> On Thu, Jun 10, 2010 at 10:38 PM, Matt Mackall <mpm at selenic.com> wrote:
>
>> On Fri, 2010-06-11 at 08:32 +1200, David Mitchell wrote:
>> > Thanks Matt,
>> >
>> >
>> >         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 think perhaps it would make sense to introduce some sort of
>> > convention for this, I don't think the current forms are expressive
>> > enough. Something similar to one of these perhaps:
>> >
>> >
>> > M foo
>> > M (sub)/bar
>> > M baz/(sub2)/qux
>> >
>> >
>> > A little arcane, so maybe:
>> >
>> >
>> > M foo
>> > S sub M bar
>> > S baz/sub2 M qux
>>
>> Yuck! Let's do it the way you had originally for now.
>>
>
> What about simply prepending the "S" flag  to the changes that appear
> within a subrepo?
>
> For example:
>
> M foo
> S sub
> SM sub/bar
> SA sub/new_file
> SR sub/old_file
>
> If the status output always included the subrepo modification line (e.g. "S
> sub"), followed by the modifications to that particular subrepo, I think
> that it would be quite easy to spot which changes are in a subrepo and which
> are not.
>
> Another case that may need to be considered is what to do when there is a
> hierarchy of multiple subrepositories which include each other.
>
>
I think it makes sense to try and get this mostly right up front, since
tools are likely to rely on this behavior. Angel's suggestion can actually
work for nested subrepos I reckon:

M foo
S lib
SM lib/bar
SS lib/nested
SSA lib/nested/new_file

Or (if that is too yuck) simply:

M foo
S lib
SM lib/bar
S lib/nested
SA lib/nested/new_file

The fact that you saw S lib earlier implies that nested must be a
sub-subrepo because it has the "lib" prefix in its path.

DM
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://selenic.com/pipermail/mercurial-devel/attachments/20100612/aca3a496/attachment.htm>