subrepo grand plan

Eric Roshan Eisner ede at alum.mit.edu
Thu Oct 20 10:31:52 CDT 2011


On Thu, Oct 20, 2011 at 08:18, Matt Mackall <mpm at selenic.com> wrote:

> On Thu, 2011-10-20 at 13:43 +0200, Dirkjan Ochtman wrote:
> > On Wed, Oct 19, 2011 at 22:21, Matt Mackall <mpm at selenic.com> wrote:
> > > a) Work towards having commit/status/diff consistent AND recursive by
> > > default
> > > b) Make commitsubrepos False by default
> > > c) Add your recursesubrepos option, None by default
> >
> > I'm with Patrick in that I prefer (b) even now. I find his argument
> > about predictability and scalability of performance compelling, but
> > mostly I find recursive commit (by default) plain scary.
>
> Would it still be scary if you had recursive diff and status by default?


I'd prefer option (b) as it prevents the most annoying situations I've
encountered from coming up in the first place. Before I figured out what the
option was for I was very paranoid about making subrepos clean to avoid the
recursive commit on repositories I don't control. Maybe a compromise is to
allow a (per-subrepo?) flag in .hgsub for commitsubrepos=false. This also
semi-fulfills the requests for read-only subrepos.

I mostly think status and diff should be recursive by default either way. If
you've changed a subrepo to a different clean revision, status/diff should
show the file changes that the next `hg commit` will reflect. The only
problem I have is that the generated diff is not completely correct if you
want to import it...
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://selenic.com/pipermail/mercurial-devel/attachments/20111020/1a71d8a5/attachment.html>


More information about the Mercurial-devel mailing list