[PATCH 1 of 8] commands: add ui.statuscopies config knob

[Gregory Szorc]

On Tue, Mar 31, 2015 at 7:00 AM, Augie Fackler <raf at durin42.com> wrote:

> On Tue, Mar 31, 2015 at 06:25:37AM -0500, Matt Mackall wrote:
> > On Sun, 2015-03-29 at 21:47 +0000, Martin von Zweigbergk wrote:
> > > On Sun, Mar 29, 2015 at 2:41 PM Martin von Zweigbergk <
> martinvonz at google.com>
> > > wrote:
> > >
> > > > On Sat, Mar 28, 2015 at 3:52 AM Mathias De Maré <
> mathias.demare at gmail.com>
> > > > wrote:
> > > >
> > > >> # HG changeset patch
> > > >> # User Mathias De Maré <mathias.demare at gmail.com>
> > > >> # Date 1427228757 -3600
> > > >> #      Tue Mar 24 21:25:57 2015 +0100
> > > >> # Node ID 60bbe7ef868927b8a8240bbcc981c66bc1480210
> > > >> # Parent  efa094701a05d58d505c3b0c3b3c73dba4e51e97
> > > >> commands: add ui.statuscopies config knob
> > > >>
> > > >> statuscopies enables viewing of copies and moves in 'hg status' by
> > > >> default.
> > > >>
> > > >
> > > > Are there tools that call "hg status" that would break in a repo
> where the
> > > > user turned this config on?
> > > >
> > > >
> > > Now that I've seen patch 2/8, I realize this is not the first config
> option
> > > that modifies output of commands. I guess tools are expected to run
> > > commands with "HGRCPATH=/dev/null" or something. So never mind my
> question.
> >
> > I think the thing people aren't sufficiently sensitive to is that about
> > 99.9% of "tools" are shell scripts and aliases.. and people get just as
> > frustrated when those break. We have lots of developers on this very
> > project who don't know about HGPLAIN (see just above), so we can't very
> > well expect tool developers and shell script authors to know much
> > better.
>
> I'm well aware that 99.9% of tools are shell scripts and aliases. This
> is behavior that people /opt in/ to, by setting a config knob. I
> already encourage most/all of these knobs for newcomers today, and
> some of them (git diffs, diff showfunc) aren't even disabled by
> HGPLAIN now.
>
> Realistically, this is going to break some number of naive shell
> scripts that don't set HGPLAIN. My contention is that those scripts
> were ALREADY going to break, because some user was going to find a
> config knob like 'ui.statuscopies' and turn it on because it solves a
> real problem he has day-to-day. That'll also be frustrating, but if we
> group things together with ui.progressive and make sure to mention
> HGPLAIN and scripting there, we have a fighting chance of people
> actually fixing their broken scripts instead of us being permanently
> unable to improve the user experience of Mercurial.
>
> Summary: I think we're *already* screwed in the way you feel
> 'ui.progressive' will break things, it's just more work for users to
> get something that actually feels coherent to a Subversion refugee.
>

I smell a use case of an "output" help topic describing the various ways
Mercurial can output data. It could have an explicit section documenting
how machines should talk to Mercurial, where we can recommend command
servers, python-hglib, -Tjson, HGPLAIN, HGRCPATH=/dev/null, etc.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://selenic.com/pipermail/mercurial-devel/attachments/20150401/2cc0e6cc/attachment.html>