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

[Peter Williams]

On 26/11/10 02:18, Dan Villiom Podlaski Christiansen wrote:
> On 25 Nov 2010, at 06:43, Peter Williams wrote:
>
>> 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? :-)
>
> No, not really. Widening the scope of a personal attack from an
> individual to all members of a group doesn't make the attack any less
> personal.
>
> The change to make -f/--force the default was made on 7 February.[1] It
> was released as part of Mercurial 1.5 on 3 March. In other words, the
> change was made 9 months ago and released 8 months ago. Until six days
> ago, no-one had complained about it, ever.

That's the thing about bugs.  They take time to appear.

>
> The change wasn't made lightly, and wasn't made without reason. It was
> made in an effort to clean up and streamline the MQ interface.

You took something useful away and added nothing that wasn't already there.

> We all
> agreed that this was sorely needed. As part of this effort, the qsave,
> qrestore, qinit and qcommit commands were deprecated.

qcommit?  I won't use this as I've never used it except for some trials 
(and had to run help to remind myself what it was). I found version 
control of the patches to be overkill and not worth the effort.  I found 
that making a gzipped tar of the patches directory was a much easier way 
to keep a history of the patches.

Taking away qinit will mean the MQ can no longer be used as a stand 
alone (i.e. on a source tree that isn't under Mercurial control) patch 
manager.  Still you don't care about other users do you?

Removing qsave will make it less useful as a stand alone tool but not 
prohibit it completely.

On the subject of stand alone use of MQ, it's quite useful in this role 
and, although both it and quilt have their faults, is in fact better 
than queue (IMHO) but only because of the availability of the -qsave 
dance for merging the patches in after a source tree update.  I even 
added support for it as an alternative back end (to quilt) in gquilt (my 
PyGTK GUI for quilt).  I used to use it to manage Linux kernel patches 
on top of CVS, bitkeeper and git (although towards the end I used to 
convert git kernel repositories into Mercurial to leverage the extra 
synergy when MQ is used on top of Mercurial).  After the initial 
conversion it's pleasingly easy to keep a Mercurial conversion of a git 
repository up to date (well done 'convert' authors).

I've never used qrestore as I only use qsave to do the update dance but 
it's a natural pair to qsave.

Personally, I think the only justification for removing functionality is 
that it's becoming too expensive to maintain or is buggy.  That no 
developers use the functionality is certainly not a valid reason.

Furthermore, it's customary when making backward incompatible changes to 
bump the major version number so that users know that it's a good idea 
to read the documentation again.  Python is a good role model in this 
regard.

> The two first
> because no-one present understood them.

What about people who weren't there?  Don't you have any consideration 
for your users.  Did you think about reading the documentation or 
consulting MQ's original author?

> The two latter because they were
> redundant. None of them are scheduled for removal. The only
> backwards-incompatible change was the one your complaining about.
>
> As I mentioned earlier, the change in behaviour for ‘qnew’ was made
> because everyone present seemed to either always use it, or had it in
> their defaults/aliases.

That isn't a good reason and in fact indicates that it was unnecessary.

> The decision was *not* made to scratch personal
> itches; it was made because consensus was that the previous behaviour
> was closer to a bug than a feature. If you wanted to affect the choice
> made, you should have voiced your criticism back then.

I wasn't at the meeting and I doubt if the majority of your users were. 
  Unless, of course, Mercurial isn't as popular as I think it is.

> That ship has
> sailed now.
>
> Name-calling doesn't strike me as terribly constructive.

If haven't done any name calling.  I've called you selfish which is an 
adjective which describes your behaviour.

> A much more
> fruitful topic would — in my opinion — be how we can minimise the pain
> for the one user — so far — that was bit by this change. The way I see
> it, there are two ways to deal with this:
>
> 1) Add a flag that would be the reverse of what --force used to do.

That would be good.

I'm not so much mad about -f behaviour being the default as I am about 
the removal of the ability to protect against forgotten qrefreshes.

With the current behaviour, I'm having to force my choice of default on 
the users of gwsmhg where before they could change it in their hgrc and 
I would honour it.

> 2) Introduce a configuration setting restore the previous behaviour.

I don't understand this one.  I can't see how it's different to #1.

> 3) Write a small extension that could be used to restore the previous
> behaviour.

Overkill.

>
> I think #1 is overkill for this. I have no preferences between #2 & #3.

I think the opposite.  #1 restores remove functionality but with a 
change in control mechanism.

>
> A few responses to the rest of your mail…
>
>> On 25/11/10 11:41, Dan Villiom Podlaski Christiansen wrote:
>>
>>> 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.
>
> I'm glad to hear that.
>
>>>> 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.
>> 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.
>
> HGPLAIN does not disable user all configuration and doesn't, for
> example, affect any of the hooks, diff and mq sections. You can see
> exactly what it affects in the source.[2]

I'm just going on what I'm told and the indications there are that it 
turns off too much to be of use to me.

>
>>>> 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?
>
> Please see ‘hg help pager’ on how to configure the extension and what
> its defaults are.

I had done that and didn't see an answer to my question.  I don't care 
about the answer enough to read it again as it isn't going effect the 
way I cope with it.

>
>> 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).
>
> So, what if someone has aliased ‘diff’ to ‘diff --color=always’?

Setting the terminal to "dumb" should disable the colourization.  As far 
as I've been able to determine either Mercurial or Python (or both) are 
smart enough not to send colourization data to a "dumb" terminal.

> Or set
> ‘defaults.qseries’ to ‘--summary --verbose’?

When I added support for qguards I found that using qseries as the basis 
for building my patch list was very inefficient especially for large 
patch sets (such as Andrew Morton's) kernel patches so I switched to 
using qguards instead.  I use it and gapplied.  This makes the operation 
O(n) instead of O(n**2) which is the best I could do using gseries as a 
starting point.

> Are you sure your tool
> handles all these properly, as well as anything even worse users might
> come up with?

I'm pretty sure that setting the terminal to "dumb" when I run the 
commands turns of all the colourization stuff.

However, things like --verbose could cause problems.  On many commands 
where I'm using them to extract data for building my displays (as 
opposed to just sticking it in the transaction log) I use templates 
which I assume disables most formatting options.

Any command that changes repository or source file state I don't really 
care about the output if it succeeds and just echo it in the transaction 
log so that log becomes a record of what the user's done.  If the 
command aborts I parse the output looking for hints such as suggestions 
to "do a refresh and retry" and if I detect them pop up a dialogue 
offering the user a choice of selecting one of the hints or cancelling 
the operation.  If the output gets mangled so badly that I can't find 
those hints all that is lost if the popup behaviour.  The failure will 
be reported via an error popup as well as in the log using the text in 
stdout and stderr.

>
> [1] <http://hg.intevation.org/mercurial/crew+main/rev/27d542bc0f5b>
> [2]
> <http://hg.intevation.org/mercurial/crew+main/file/44b26a87f73e/mercurial/ui.py#l79>

What?

Anyway there's an upside to all this.  Both MQ and quilt have 
faults/shortcomings  (MQ's are getting worse) so the answer is to create 
a new patch stack management tool that addresses these issues and I've 
build one.  It won't be a Mercurial extension as that would compromise 
its use as a stand alone tool but I will try to make it aware of SCM 
(not just Mercurial) on the underling source tree to facilitate such 
things as merging after an update and doing the equivalent of qfinish 
(which IMHO is the only positive change to MQ since its original version).

Peter
PS After you've finished all your changes you will have restored quilt 
to its former status as best patch management tool.