[BUG] The -f option to qnew has been removed

Peter Williams pwil3058 at bigpond.net.au
Wed Nov 24 23:43:21 CST 2010


On 25/11/10 11:41, Dan Villiom Podlaski Christiansen wrote:
> On 25 Nov 2010, at 01:19, Peter Williams wrote:
>
>> For you but not for everybody. Why didn't you just put -f in the
>> default options for qnew in your .hgrc file? Why break backward
>> compatibility just to scratch a personal itch?
>
> The decision to change the behaviour for ‘qnew’ without the -f/--force
> argument was made at the Paris Sprint in February. It was hardly
> Martin's ‘personal itch’ that needed scratching. Consensus was that the
> current behaviour of ‘qnew’ didn't make sense,

The original qnew worked in a perfectly sensible way for the (original) 
intended users i.e. those migrating from quilt or Andrew Morton's patch 
management scripts.  The original documentation made it very clear that 
this was the workflow which MQ was designed for.

To me (a long time user of MQ and quilt beforehand) the new behaviour 
does^^^idn't make sense (see below where I finally twigged).  Why would 
one want "-f" as the default when one knows from experience (with one's 
personal workflow) that by far the most common mistake one makes is 
forgetting to do a refresh before running qnew?  If one made this 
mistake the old qnew caught if for you.  In the far less likely 
situation, where one's started making changes to the sources before 
running qnew one still has "qnew -f" to fall back on.  Perfection!

That MQ was useful for other workflows (even if not perfect) is/was 
good.  If changes needed to be made to make it more useful for those 
other workflows then they should be added as extensions/enhancements. 
If that isn't adequate then the MQ code should have been used as a basis 
for a new hg extension that met the other workflow's needs.

As I said above, I was having trouble figuring out how anyone would 
think the new behaviour is more natural but I've since realised that 
someone coming from unassisted diff/patch use probably thinks "make 
changes then create patch" is the normal way to do things (ignoring the 
need two have two copies of the source tree which is necessary in 
unassisted diff/patch use).  But a quilt (or similar) tool user thinks 
"create patch, make changes and refresh patch".  Both are valid views of 
the world for something such as MQ (sitting on top of an SCM) and it 
used to cater to both.  Now it doesn't.

BTW the "make changes then create patch" doesn't work with quilt because 
it has no way of knowing what the sources looked like before you made 
the changes.  The same thing applies if MQ is used "stand alone" to 
manage patches on a source tree that isn't under hg control (it is 
possible even if unlikely).  So to my mind the "create patch, make 
changes, refresh patch" is the superior workflow as it works in more 
situations.  But I wouldn't force it on anyone.

> and that everyone present
> always used ‘qnew -f’ or had it in their configurations as a default or
> an alias.

Thus indicating that there was no need to change qnew as there was a 
perfectly adequate work around available for those who wanted -f as the 
default behaviour.

By leaving it as it was ALL users could choose the default behaviour 
that they wanted.  With the new behaviour ALL users are forced to have 
"force" as the default behaviour.

So, I repeat, it was a completely gratuitous and selfish change although 
it seems that the selfishness extends to more than Martin.

> There's no need to make this personal.

I extend the accusation of selfishness to the group so it's no longer 
personal.  Happy?  :-)

>
> That this change broke your frontend is unfortunate, but it's too late
> to reverse it now. The change has been out there for more than half a year…

It didn't break my front end.

It (almost) caused a stack of patches that I was was working on to be 
compromised (by putting changes in the wrong patch) because it failed to 
warn me that there were unrefreshed changes to the patch I had been 
working on.  Fortunately, I noticed in time did a qpop and qfold and 
then repeated the qnew.  I would have been really upset if I hadn't 
noticed before I'd made considerable changes to that new patch (making 
the recovery more difficult).  I try (but don't always succeed) to make 
my patches small and logically related.  qnew used to help me in this 
endeavour. Now it doesn't and I've forced to take other measures.

An unsuspecting command line user in the same situation would not have 
been as lucky.

>
>> I'm of the opinion that my scripts should honour the user's personal
>> configuration and I don't want to override any except colourization. I
>> override colourization by setting the terminal for hg commands that I
>> run to "dumb".
>
> HGPLAIN is the intended and documented way to disable user
> customizations that might interfere with frontends. For example, aliases
> allow users to make any command point to something else, and setting
> HGPLAIN disables this.

If a user wants "hg add" (for example) to do something other than what 
it would normally do then I don't want to override that in my GUI.  When 
the user selects "Add" in my GUI I want it to do what he expects "hg 
add" to do when he types it at the command line.

The same goes for the users default options and any hooks.

The idea is to provide an interface to Mercurial as configured by the user.

For instance, in the case of the original qnew if the user had "-f" in 
his default options for qnew then gwsmhg wouldn't pop up dialogues 
saying that there are uncommitted/unrefreshed changes and asking whether 
he wanted to force when he hit the "New Patch" tool bar button.  The 
"-f" default option would have caused qnew to behave as the user desired 
and added the changes to the new patch and not reported a problem to 
gwsmhg (so no pop up dialogue).

Other examples, are:
-- honouring "--git" options to qrefresh, etc.
-- not overriding hooks in place to prevent bad things, such pushing 
when MQ patches were applied, happening.

Basically, what I'm saying is that HGPLAIN is too much of a scatter gun 
to be of any practical use (at least, for me).  If a script writer needs 
to disable particular user customizations then he needs a much more 
targetted tool.

Of course, I could use HGPLAIN and then offer a separate configuration 
mechanism for gwsmhg but I don't think that would be very user friendly 
for what should be obvious reasons.

>
>> What's "pager"? I couldn't see reference to it in help pages that I
>> tried (rev, status). It sounds like something that I might have to
>> worry about.
>
> ‘pager’ is an extension that pipes the output of Mercurial through a
> pager, e.g. ‘less’. By default, it will only be active when ui.formatted
> is true, which is the default when standard output is a terminal. The
> pager extension was added in Mercurial 1.0.

OK, found it.  It doesn't seem to work for all commands.  With no 
configuration changes it works for log but not status.  Is that normal? 
  In other words, is there a default "ignore" list?

In any case, the --pager option enables this feature to be turned off 
when a command is run so this extension shouldn't cause gwsmhg any 
problems (after I make the necessary changes).

Peter


More information about the Mercurial-devel mailing list