Marking subrepos in 'hg status'

[Didly Bom]

On Monday, October 11, 2010, Martin Geisler <mg at aragost.com> wrote:
> Didly Bom <didlybom at gmail.com> writes:
>
> Hi Angel,
>
> I'm adding Erik to the CC list -- he is our new employeee at aragost.
>
>> On Mon, Sep 27, 2010 at 6:26 PM, Martin Geisler <mg at aragost.com> wrote:
>>
>>> Consider a situaion like this:
>>>
>>>  $ hg status -S
>>>  M dir/x.txt
>>>  M sub/a.txt
>>>  A dir/y.txt
>>>  A sub/b.txt
>>>
>>> where sub/ is a subrepository and dir/ is just a folder.
>>>
>>> In some older discussions, people asked for an indicator of when a
>>> file is inside a subrepository and when it is inside a directory -- I
>>> felt the most natural choice was to write sub/ for the
>>> subrepositories.
>>>
>>> But in the case above, it is hard to see what to write for the line
>>> with 'A sub/b.txt' -- should it look like this:
>>>
>>>  $ hg status -S
>>>  M dir/x.txt
>>>  M sub/
>>>  M sub/a.txt
>>>  A dir/y.txt
>>>  A sub/
>>>  A sub/b.txt
>>>
>>> That is strange since the subrepo has not been added. An alternative
>>> would be to move the recusion up, so that all status lines are kept
>>> together for each subrepo:
>>>
>>>  $ hg status -S
>>>  M dir/x.txt
>>>  A dir/y.txt
>>>  M sub/
>>>  M sub/a.txt
>>>  A sub/b.txt
>>>
>>> which I think works better, though it results in scrambled order of
>>> added and modified files. What do you guys think?
>>>
>>
>> Martin,
>>
>> In my opinion, the first option is _really_ confusing. I think that
>> option two is much better and also makes much more sense. After all
>> you could say that the files changed, added or remove within a subrepo
>> are the details of the modification of that subrepo. As such it makes
>> sense to show them immediately after the subrepo modification line.
>
> Right, I agree. That is why I've asked Erik to work on patches for the
> second option and he sent them to the list here:
>
>   http://mercurial.markmail.org/thread/lsdk6eoj5okknrg5
>
> There has been no comments on those patches, so please try them and let
> Erik know what is good and what is bad. We have to get input from users
> on these features -- we're not yet using subrepos for the Mercurial code
> itself, so you guys have to help us.

 The main problem I have with that is that we use windows. I don't
know of an easy way to try these patches since I don't know how to
build mercurial :(

> I hope Erik can join in and comment on your other suggestions too.

That'd be great!

Cheers

Angel