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

[Dan Villiom Podlaski Christiansen]

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.

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. We all  
agreed that this was sorely needed. As part of this effort, the qsave,  
qrestore, qinit and qcommit commands were deprecated. The two first  
because no-one present understood them. 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. 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. That  
ship has sailed now.

Name-calling doesn't strike me as terribly constructive. 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.
2) Introduce a configuration setting restore the previous behaviour.
3) Write a small extension that could be used to restore the previous  
behaviour.

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

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]

>>> 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.

> 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’? Or  
set ‘defaults.qseries’ to ‘--summary --verbose’? Are you sure your  
tool handles all these properly, as well as anything even worse users  
might come up with?

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

--

Dan Villiom Podlaski Christiansen
danchr at gmail.com


-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 1943 bytes
Desc: not available
URL: <http://selenic.com/pipermail/mercurial-devel/attachments/20101125/04a47d63/attachment.bin>