subrepo wish list

Michael Ekstrand michael at elehack.net
Wed Apr 14 20:42:53 CDT 2010


On 04/14/2010 08:31 PM, Steve Losh wrote:
> On Apr 14, 2010, at 9:27 PM, Michael Ekstrand wrote:
> 
>> On 04/14/2010 08:09 PM, Steve Losh wrote:
>>> On Apr 14, 2010, at 6:18 PM, Michael Ekstrand wrote:
>>> 
>>>> After working with subrepos in Mercurial for some weeks now, I
>>>> have been getting somewhat frustrated with the remaining user
>>>> experience holes in them.  But with that, I also have proposals
>>>> for what would make this experience better.
>>>> 
>>>> The purpose of this message is not to demand "write my feature!
>>>> fix my bug!", but rather to share my thoughts based on some
>>>> subrepos experience, see if there are already-existing methods
>>>> to achieve my goals, and start a conversation about how best to
>>>> fill these gaps.
>>>> 
>>>> For subrepos to be near-perfect for me, two things are missing
>>>> or "broken": * Status support is nonexistent, as near as I can
>>>> tell * Commit recursively auto-committing doesn't fit well w/
>>>> my workflow
>>>> 
>>>> For the first, it looks like there has already been some
>>>> discussion on doing this and some submitted patches.  It seems
>>>> to me that there are 3 states a subrepo can be in: * Unchanged,
>>>> and thus suppressible from status display * Changed but
>>>> committed: the subrepo is changed from a parent repo
>>>> perspective, but itself has no uncommitted changes. * Possibly
>>>> changed and dirty: the subrepo has uncommitted changes, and its
>>>> last checked-in status may or may not be the same as recorded
>>>> in .hgsubstate.
>>> 
>>> Personally I'd find the following two features helpful:
>>> 
>>> * 'hg status --suprepos' would show *all* uncommitted changes, 
>>> including any in subrepositories.  Maybe an extra character could
>>> be added to the output to distinguish changes in subrepos from
>>> changes in the main repo, but that's not a huge deal.
>> 
>> That's pretty much what I'm thinking of, with one addition: a line 
>> showing the subrepo itself if it is changed and/or dirty.  That
>> seems to be a useful piece of 'status'.
> 
> The reason I wouldn't want to show that is because status is supposed
> to show *files*.  The first sentence of 'hg help status' is:
> 
> Show status of files in the repository.
> 
> Showing whether a subrepo as a whole is dirty would be useful, but it
> seems like it would break the "do one thing and do it well"
> philosophy of Mercurial.
> 
> I'm not sure where the best place to put the "which subrepos are
> dirty" output would be.

Hmm.  I think of a subrepository as a "file" which happens to be a
repository.  I know that isn't how they're implemented, but it's how I
think of them and try to work with them functionally, and I think it's a
rather clean way to do so.  In that frame of mind, it makes sense to
display them in the status listing.

But perhaps there is another place.  I had planned that, should such a
--subrepos option be added to status, I would make an 'rstatus' alias to
it; perhaps 'rstatus' could be a new command (via an extension?) to list
the status including changed subrepos.

- Michael



More information about the Mercurial mailing list