Marking subrepos in 'hg status'

[Masklinn]

On 2010-10-20, at 10:37 , Martin Geisler wrote:
> Matt Mackall <mpm at selenic.com> writes:
>> On Tue, 2010-10-19 at 09:26 +0200, Martin Geisler wrote:
>>> timeless <timeless at gmail.com> writes:
>>>> On Mon, Oct 18, 2010 at 6:05 PM, Martin Geisler <mg at aragost.com> wrote:
>>>>> With your suggestion we can have
>>>>> 
>>>>>  M sub1/
>>>>>  M sub1/a
>>>>>  M sub2/
>>>>>  M sub2/x
>>>>>  A sub1/
>>>>>  A sub1/b
>>>>>  A sub2/
>>>>>  A sub2/y
>>> 
>>> I agree -- I think this is a nice and consistent way to show the
>>> status.
>> 
>> I don't like it. We've always only listed files.
> 
> Yes... but if one thinks of subrepos as versioned directories then it
> makes some sense.
> 
>> In my view, the end goal of subrepo support is for you -not to have to
>> be aware you're using subrepos-. I think this is more or less the
>> experience in SVN and CVS.
> 
> Yes and no... some things are not very transparent in Subversion and
> status is quite verbose in that it first marks the "subrepo" with an X
> status and then reports the status recursively:
> 
>  $ svn status
>  X       b
> 
>  Performing status on external item at 'b'
>  M       b/b.txt
> 
> On the other hand, you can transparently access the subrepo:
> 
>  $ svn diff b
>  Index: b/b.txt
>  ===================================================================
>  --- b/b.txt     (revision 1)
>  +++ b/b.txt     (working copy)
>  @@ -1 +1,2 @@
>   b
>  +b
> 
> though a plain diff gives no output or indication of the dirty subrepo:
> 
>  $ svn diff
> 
> So it's a bit inconsistent. Also, a commit will not recurse and by
> defalt there is no tracking of which revision corresponds to which (no
> .hgsubstate file).
> 
>> That goal is obviously still a ways off, but adding new types of
>> status entries is not a step in the right direction.
>> 
>> An alternative:
>> 
>> hg sub -l
>> 
>> -l --list       show subrepository and their states
> 
> Something like that could be nice. Perhaps it could also get --add so
> that users can do
> 
>  hg subrepo --add foo/bar http://foo/bar
> 
> and Mercurial will then checkout http://foo/bar as needed. It is not
> like it's hard to edit the .hgsub file manually, but it is slightly
> confusing for people to sync their working copy with the edited .hgsub
> file afterwards.

Wouldn't that shortcut look better on `hg add`? As in, you add a remote repository to start tracking it as a subrepo? `hg add http://foo/bar` would add the directory at the `bar` path, as if we'd cloned it manually and then grafted it?