[PATCH 0 of 6] Recursive status and diff for subrepositories
tim.henigan at gmail.com
Wed Sep 1 11:44:03 CDT 2010
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:
.hgsub (refers only to subrepo_1)
.hgsub (refers only to subrepo_2)
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
>> 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:
> 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.
More information about the Mercurial-devel