[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