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

[Augie Fackler]

On Nov 25, 2010, at 7:27 PM, Peter Williams wrote:

> On 26/11/10 02:18, Dan Villiom Podlaski Christiansen wrote:
>> On 25 Nov 2010, at 06:43, Peter Williams wrote:
>> 

[...]

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

I think the larger point here was that it took *8 months* for anyone to complain, and we got a fair amount of thanks from a variety of sources in the interim. 

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

Sometimes user interface work is about simplification through reduction.

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

How has mq *ever* worked on a tree that wasn't under hg control? I don't see how that's even possible. Perhaps you mean on a patch queue not under hg control?

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

Again: it wasn't removed, it was deprecated. The reason for doing that twofold: 1) nobody really understands qsave anymore as a command and 2) it's trivial to import a queue into hg and use real version control instead of qsave-based snapshots, which ends up being faster and safer on the whole.

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

Perhaps you could (calmly) explain your use case for qsave and qrestore more clearly, and be open to us not understanding why you don't want to directly use hg to manage the history of the patches.

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

Agreed there, but this is a change to an extension, not hg itself.

> Python is a good role model in this regard.

Hardly. 2.6 broke *all* programs that ever used 'with' as a variable or function name. That wasn't the null set.

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

MQ's documentation has honestly always felt a bit thin, and the majority of those that have actually done major work on MQ since its inception were at the sprint.

[...]

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

I can see why you'd feel strongly about this - for my part, I can understand the desire for the old behavior even if I personally find the old behavior annoying. That said, I think 2 is better than 1 because we're *actively* discouraging use of [defaults],

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

Agreed.

[...]

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

How so? What (specifically) does it turn off that is bad for your scripting? It's important that we get such feedback so we can understand how the API might be better for users. For some background: HGPLAIN is intended for users that are scraping the output of hg commands, something we support as an API. Are you scraping the output of the commands, or simply chaining commands together and showing output to the user?

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

--color=always means "always use color, even if stdout doesn't look like a tty," so this would probably cause you grief (assuming I understand your use case.)

[...]

I'm sorry this is so frustrating for you. I'd love to have everyone calm down and see if we can't come up with some kind of solution that's workable for everyone (that is: keeps the common-case behavior while still making it reasonably easy to get the "safer" old behavior.)

Thanks,
Augie