Subrepo status/diff/revert

[Tim Henigan]

On Mon, Aug 23, 2010 at 12:10 PM, Martin Geisler <mg at lazybytes.net> wrote:
> Tim Henigan <tim.henigan at gmail.com> writes:
>
> I am working for another client to fix these problems. I have added the
> requested enhancements to the wiki:
>
>  http://mercurial.selenic.com/wiki/Subrepositories#Wanted_Feature_per_Command

Excellent.  This summary really helps direct the conversation.  Is
this intended to track the features you plan to implement for your
client or can others add plans/requests there as well?


> Fixing 'hg status' and 'hg diff' is first on my list since it is quite
> confusing that 'hg commit' recurses into a subrepository when 'hg
> status' gives no output.
>
> I have patches for this on Bitbucket:
>
>  http://bitbucket.org/mg/subrepo-mq
>  http://lazybytes.net/tmp/subpo-mq/

hmmm...BitBucket is still down and I was not able to clone the 2nd
URL.  I get the following Traceback when using hg v1.6.1023:
    ...omitted several lines
      File "hgext\bookmarks.pyo", line 371, in listbookmarks
    AttributeError: 'statichttprepository' object has no attribute '_bookmarks'


> The biggest problem right now is matching paths inside subrepos, please
> see this mail:
>
>  http://mercurial.markmail.org/message/en22vxyyqgbgbllb

I noticed this thread on the list, but did not read it carefully.  I
will take another look.  Thank you for the pointer.


>> With that in mind, I plan to develop an extension to:
>>
>>     1) Modify `hg status` to show when a subrepo SHA1 does not match
>>        the SHA1 in .hgsubstate. My current plan is to output 'S
>>        subrepo/dir' when a mismatch is found. This is the same action
>>        done in TortoiseHg today.
>
> I kind of like this -- the wiki suggests a slightly different output:
>
>  $ hg status
>  M sub-a/
>  M sub-b/
>  M sub-b/file.txt
>
> Here 'M sub-a/' means that the sub-a subrepo is not at its right
> revision and where 'M sub-b/' means that there are uncommitted changes
> in sub-b (as indicated by the next line).

My intention was to force the user to navigate to the subrepo and do a
separate status/diff there in order to find the exact set of changes.
All I need from `hg status` is to know if the subrepo either 1) points
to a different revision or 2) has uncommitted changes.

I want the same information from `hg diff` as well.  However for `hg
diff`, I planned to actually modify .hgsubstate to show the new
revision (in case 1) and/or the revision with a "+dirty" flag (in case
2).  However, I don't know if it is safe for `hg status` to change
.hgsubstate.


>>     2) Modify `hg revert` to update subrepos to the SHA1 listed in .hgsubstate.
>
> It is actually a good question what 'hg revert --all sub/' should do. My
> client has not said how they want this to be handled so it's in the
> wiki.
>
> I guess it should recurse, that is, do 'hg revert --all' inside the sub/
> repository. Now, the next question is how to reset the state of the
> subrepo to what .hgsubstate say? Perhaps we could let
>
>  hg revert --no-recurse sub
>
> do that? I hope we can find an interpretation that is consistent and
> natural...

I feel that revert should do the following by default:
    1) `hg revert --all` any uncommitted changes in the subrepo
    2) `hg update` the subrepo to the revision listed in .hgsubstate

I have a working extension which does #2 via a dedicated command
(subrepo-revert), but I want to change this extension to wrap the
existing revert command.  I have also considered adding an option
(maybe named --resync) which would re-clone the subrepo.  This would
insure that the local clone does not have any additional commits.

Thanks,
Tim