subrepo grand plan

[Jason Harris]

On Oct 20, 2011, at 6:43 AM, 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
>> 
>> 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...

+1

I also think the default should be (b)

Cheers,
   Jas