subrepo wish list
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
>> 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
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.
More information about the Mercurial