subrepo grand plan

[Matt Mackall]

On Thu, 2011-10-20 at 08:31 -0700, Eric Roshan Eisner wrote:
> 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...

I do not feel that this answers the question.

-- 
Mathematics is the supreme nostalgia of our time.