subrepo wish list

Steve Losh steve at stevelosh.com
Wed Apr 14 20:31:18 CDT 2010


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.

> 
>> * '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
> 
> _______________________________________________
> Mercurial mailing list
> Mercurial at selenic.com
> http://selenic.com/mailman/listinfo/mercurial



More information about the Mercurial mailing list