subrepo wish list

Michael Ekstrand michael at elehack.net
Wed Apr 14 20:27:15 CDT 2010


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

> * 'hg summary --subrepos' would include a line telling you if
> committing in your main repo would update the .hgsubstate file --
> i.e. subrepo X is currently at a different revision than the
> .hgsubstate lists.

That would also be useful, I think.

>> Commit is a bit more complicated, and my ideal workflow is not 
>> backwards-compatible.  Right now, commit recursively tries to
>> commit subrepositories before committing the current repository.
>> It would be quite nice if there were an option at least to modify
>> this behavior.  My workflow would be best served, as near as I can
>> tell, by the following: * If subrepositories are clean, commit and
>> update .hgsubstate if necessary.  From a UI perspective, treat
>> directories as files, so I can commit the updated state of subrepos
>> selectively. * If subrepos are dirty, fail.  Require a --force
>> option to proceed; in that case, update .hgsubstate but do not
>> commit the nested repository. Have another option to do the
>> recursive commit.
>> 
>> Basically, I don't want my subrepos transparently committed for me:
>> I want to manually commit them every time.
> 
> If we want to stay backwards-compatible with the current behavior, we
> could offer a "[subrepos] autocommit = False" option in hgrc to
> disable the automatic commit of changes in subrepos.
> 
> Selectively committing individual updates to subrepos seems more
> difficult -- I think it would require a new option to commit and
> personally I don't see myself using it a lot.  Others might feel
> differently.

I don't think I would use it a whole lot either; I mostly included it to
parallel my thinking about hg status and for some uniformity.  I don't
think I'd miss it too much; if a selective commit is required, I could
just update the subrepository to the desired revision before committing
the parent repository.

- Michael



More information about the Mercurial mailing list