subrepo grand plan

[Dirkjan Ochtman]

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
>
> My favorite is (a) because all work here is forward progress towards
> having subrepos more uniformly integrated. This will make subrepos
> better for everyone with no config settings needed. I think the big
> hurdle here (getting these three commands consistent +
> add/forget/remove) is really not that hard given the existing groundwork
> you've set in.
>
> I ought to have done (b) to start with or very early on, but the option
> never occurred to me. Now I frankly think it's half a step backwards.
> It'll solve a big issue for new users (great), but may upset some
> existing users (which usually trumps). Given that we've got four months
> until the next release this could possibly be in, I'd rather see us
> hurry up and do (a).
>
> And (c) I think is not especially better than the status quo. New users
> will still have to find it to get the consistent experience, and then
> when we finally do (a), they'll have to go back and turn it off. Then
> there's collateral maintenance issues, tool awareness and so on. Given
> that it's purely a stop-gap measure, it's a half-step backwards plus a
> log to trip over when we start going forward again.

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.

It's way too easy to inadvertently commit in the child repo (and only
notice on push), and I thoroughly dislike the fact the subrepo gets
the commit message from the parent repo by default, which often
doesn't describe the changes in the subrepo very well. Also, after
you've inadvertently committed a subrepo and you want to roll that
back, you have to do an incredibly awkward dance where you rollback
the subrepo, commit again something more appropriate (e.g. better
commit message or only parts of the changes), then you have to fix up
the parent repo which is a pain because the recorded revision for the
subrepo no longer exists, etc...

Cheers,

Dirkjan