Subrepo status/diff/revert

[Martin Geisler]

Tim Henigan <tim.henigan at gmail.com> writes:

> 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?

Feel free to edit it -- I've agreed with the company that I'll implement
the features in accordance with what the other Mercurial developers
think and what the community wants. The current page is the proposal
From the company.

>> 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'

Yes, I also got that error, so I temporarily disabled the bookmarks
extension to do the clone. I've now fixed the error in revision
1938954354ec which will be part of the next stable release.

>>>     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.

I see. The company I work for are after a more seamless approach where
they can do 'hg log sub/a.txt' or 'hg add sub/b.txt' and so on without
having to worry about crossing subrepo boundaries.

> All I need from `hg status` is to know if the subrepo either 1) points
> to a different revision or 2) has uncommitted changes.

Just showing if a subrepo is dirty is nice because it's simple and easy.

> 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.

That sounds nice. I'm not going to work on revert so please give it a
shot.

> 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.

It could just strip the subrepos, but this sounds dangerous. Mercurial
should not throw away changesets -- if there are extra changesets, then
they were probably made for a reason :-)

-- 
Martin Geisler

Mercurial links: http://mercurial.ch/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL: <http://selenic.com/pipermail/mercurial-devel/attachments/20100823/31bd4125/attachment.pgp>