[PATCH 0 of 6] Recursive status and diff for subrepositories

[Tim Henigan]

On Wed, Sep 1, 2010 at 11:24 AM, Martin Geisler <mg at lazybytes.net> wrote:
> Tim Henigan <tim.henigan at gmail.com> writes:
>
>> On Wed, Sep 1, 2010 at 10:14 AM, Martin Geisler <mg at lazybytes.net> wrote:
>>> Martin Geisler <mg at lazybytes.net> writes:
>>>
>> I like the direction of these patches very much. They will greatly
>> improve the usability of subrepos.
>
> Thanks a lot for giving them a try, it's much appreciated :)

No problem.  This is an important set of features.

I am still trying different scenarios.  One new question/issue:
The new 'hg status' does not seem to handle nested subrepos.
For example, if I have the following:
    top-level-repo/
        .hgsub (refers only to subrepo_1)
        .hgsubstate
        subrepo_1/
            .hgsub  (refers only to subrepo_2)
            .hgsubstate
            subrepo_2/    this is a subrepo

If subrepo_2 has a locally modified file, then calling 'hg status -S' from
'top-level-repo' does not show the modification.  However, 'hg diff -S' does
show the change.  It appears that 'hg diff' knows to recurse into nested
subrepos, but 'hg status' does not.


>> However, it seems that these commands should also show changes to the
>> revision of the subrepo.
>>
>> For example, if I do the following:
>>   $ hg update -R subrepo -r <different revision than the one in .hgsubstate>
>>   $ hg status -S
>>
>> The output shows something like:
>>   $ R subrepo/file.py
>>
>> That is, the file status changes are shown but not the reason for them
>> changing (subrepo was moved to a different revision).
>>
>> It would be helpful if both status and diff could show that the
>> revision of the subrepo has changed, in addition to the actual file
>> status.
>>
>> Ideally, this would show as a modification of the .hgsubstate file in
>> the top-level repo.  Then the standard 'hg status' command would show
>> that .hgsubstate was modified and 'hg diff' would show the change to
>> the revision (including the before and after revisions).
>
> Yes, modifying the .hgsubstate file seems like a good way to indicate
> the change.
>
> I was just about to write that it gives a true picture of what will be
> committed by the next commit, but that is not 100% accurate: after
> these commands,
>
>  $ hg update -R subrepo -r <X>
>  $ echo hehe >> subrepo/a.txt
>
> we cannot really show
>
>  $ hg diff .hgsubstate
>  <X> subrepo
>
> since subrepo is modified and so a commit will produce revision <Y>
> which is then put into .hgsubstate.
>
> So I guess we should instead put
>
>  <X>+ subrepo
>
> into .hgsubstate -- the user will know that this means 'subrepo' is at
> revision <X> but is dirty.

I considered doing this for an extension I was writing, but was concerned that
if I modified .hgsubstate to show some flag after <revision>, it would break
other commands.  I have not researched where .hgsubstate is used.


>> Also, it would be helpful if there was a config option which allowed
>> the 'subrepos' flag to be enabled by default (via the user's hgrc).
>
> You can use defaults for now:
>
>  [defaults]
>  status = --subrepos
>  diff = --subrepos

Ahhh...excellent.  I had forgotten about this feature.


> But I think it would be nicer to have a general setting like you suggest
> that turns recursion on or off in general.

Agreed.

-Tim Henigan