subrepos: recursive status/diff with ui.commitsubrepos=True

[Matt Mackall]

On Thu, 2011-12-01 at 09:32 +0100, Martin Geisler wrote:
> Matt Mackall <mpm at selenic.com> writes:
> 
> > On Wed, 2011-11-30 at 12:51 +0100, Martin Geisler wrote:
> >> Hi everybody,
> >>
> >> We recently changed the default for ui.commitsubrepos to False. The
> >> behavior of commit, status, and diff now look like this:
> >>
> >>           | recurses   | recurses        | recurses with
> >>           | by default | with --subrepos | ui.commitsubrepos=B
> >>   --------+------------+---------------- +--------------------
> >>   commit: | False      | True            | B
> >>   status: | False      | True            | False
> >>   diff:   | False      | True            | False
> >>
> >> I've added a new, third column to show how the ui.commitsubrepos
> >> option impact the three commands.
> >
> > I think your table is extremely misleading, indeed it has misled me
> > before. Let's rewrite it:
> >
> >         (default)
> >         commitsubrepos=False  commitsubrepos=True  with --subrepos
> > commit  no recurse / abort    recurse              recurse
> > status  no recurse            no recurse           recurse
> > diff    no recurse            no recurse           recurse
> 
> I like your table too! :) What David talk about it to make column two
> consistent with column three so that commitsubrepos=True becomes the
> same as adding --subrepos on the command line.
> 
> >> The table is almost consistent..., except for the third column. Can
> >> we make it consistent by putting B's all the down in that column?
> >
> > I think the current table's fine. The center column shouldn't be
> > changed (what you're proposing) because it's what people have to use
> > to get the legacy behavior but we really just want to pretend this
> > column doesn't exist moving forward. The third column is obviously
> > correct and is not particularly worth talking about. The only
> > interesting place is column one.
> 
> Well, apparently David also thinks column two is important.

Ok, I think I've been as clear as I can on why column two will never
change.

> >> When I proposed the ui.recursesubrepos option I had B's all the way
> >> down in the last columns. The objection was that tools would be
> >> confused. I tried to argue that HGPLAIN should turn the new behavior
> >> off. I don't think this was countered further and I believe that
> >> HGPLAIN should make the change "tool-safe" until full transparency is
> >> achieved.
> >
> > It certainly was countered!
> 
> Mkay, but after the mail you quote below, I wrote that HGPLAIN should
> reset the setting. So I don't think the arguments apply, which I also
> wrote back in September.
> 
> >         Making it a config setting doesn't help (this was explicitly
> >         rejected in March[1]). In general, we shouldn't put any major
> >         behavior changes under config settings:
> >
> >         - experts getting a surprise when at a random user's keyboard
> >         is BAD
> 
> This is distributed version control -- make a clone and use your own
> keyboard! :-) That's of course a joke, but I do believe that we need
> configuration options to make a truly powerful tool. The expert users
> should be expert enough to know about the config options.

Really? I know I've personally wasted hours of my life debugging
numerous instances of "user put stupid option in [defaults] and then
baffled everyone on IRC". I guess it's unfortunate that the real experts
like yourself weren't around those days.

> >         - a tool getting unexpected behavior because of a UI setting
> >         is BAD
> 
> Hmm... Now that I think more about your response, I take it that you
> don't expect all tools to set HGPLAIN? I can definitely see why people
> would forget to set it in a cronjob... so we need to agree with
> ourselves about this: do we require that tools set HGPLAIN, or do we
> also support tools that don't set it?

I expect well-written, widely-used tools to do it but I don't expect
most tools to be either well-written or widely-used. I expect the vast
majority of tools to be written by busy sysadmins while cobbling
together build environments.

When the busy sysadmin discovers that Bob's fondness for pretty colors
in status confuses his tool, he spends an hour poking around on the wiki
and the mailing list and discovers HGPLAIN. Right, let's just turn that
on. But when he comes in the next morning, he discovers his manager
waiting in his office because now his tool is mysteriously ignoring the
magic subrepo setting he spent a whole day researching and a whole week
getting everyone to set in their hgrc files and everyone's builds and
commits are making a horrible mess. Now busy sysadmin is rightfully
annoyed because a) HGPLAIN should be harmless and b) there's no good
fix.

'Plain' turns off the 'fancy' fluff bits that might interfere with
tools. This is not that.

-- 
Mathematics is the supreme nostalgia of our time.