subrepo grand plan

[Matt Mackall]

On Wed, 2011-10-19 at 21:09 +0200, Martin Geisler wrote:
> Matt Mackall <mpm at selenic.com> writes:
> 
> > On Wed, 2011-10-19 at 09:42 +0000, David.Sedlock at lantiq.com wrote:
> >
> >> commitsubrepos.
> >>
> >> This is the option we wanted Martin to use so we could get consistent
> >> behavior of commit/status/diff.
> >>
> >> The existence of this option cannot be consistent with your statement
> >> "We absolutely cannot have a naked 'hg commit' commit everything but
> >> subrepos."
> >
> > You haven't been listening carefully enough. There are THREE choices:
> >
> > 1) the current default behavior
> >    'a naked commit ... recurses'
> > 2) Patrick's commitsubrepos=False behavior
> >    'a naked commit ... aborts if subrepos are modified'
> > 3) the thing that everyone asks for (commit only the main repo)
> >    'a naked commit ... commits everything but subrepos'
> 
> I just realized that there might have been some confusion here!
> 
> The option I proposed is like *option 2*, not option 3. In other words,
> it does not allow you to commit the main repo alone. The recursesubrepos
> does two things:
> 
> 1) it sets  commitsubrepos = recursesubrepos for commit
> 2) it sets opts['subrepos'] = recursesubrepos for status and diff
> 
> That's all -- the goal is to let the user set recursesubrepos=False and
> get consistency between the commands as in this table:
> 
>   If ui.recursesubrepos is set to a boolean B, then we have:
> 
>             | recurses   | recurses
>             | by default | with --subrepos
>     --------+------------+----------------
>     commit: | B          | True
>     status: | B          | True
>     diff:   | B          | True
> 
> The --subrepos flag is new for commit, it lets the user override the
> recursesubrepos option on the command line when needed.
> 
> I'm sorry if my explanation was confusing in the original patch:
> 
>   http://selenic.com/pipermail/mercurial-devel/2011-September/034354.html

Ok, you're right. I managed to misread both your description AND your
code the last time around. Thanks for having patience with me.

But I'm still not super-excited about this. Let me lay out some related
options for comparison:

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'd really rather get to the point where this whole issue is in the
rear-view mirror.

Here's my subrepo Top 5 wishlist:

1) nested repo paths on hosting services
2) make 'hg add/forget/remove sub/foo' work so that we can make
status/diff recursive
3) make subrepos track what they last pulled so we don't waste time
trying to push clean / read-only repos
4) more parity between hg and git/svn subrepo support
5) better docs / use cases on the wiki

-- 
Mathematics is the supreme nostalgia of our time.