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

Peter Williams pwil3058 at bigpond.net.au
Thu Nov 25 23:26:29 CST 2010


On 26/11/10 13:44, Augie Fackler wrote:
>
> 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.

You have to keep poking the bear, don't you.  One complaint is enough 
for a bug to be valid.

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

Sometimes it's not.  Mostly it's not.

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

Very well as it turns out thanks to the original designers forethought 
and excellent design.

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

My statement was in one of the FUTURE tenses and was predicting the 
effects of the mooted change.

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

The fact that I say that I find them useful should be sufficient.  It 
costs nothing to leave them there.

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

It's part of the Mercurial package.

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

The key part of your statement is "done major work on MQ".  The ones who 
matter are the users who've "done major work with MQ".  More indication 
of your selfishness and lack of consideration of users.

>
>>> 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],

At last, an admission that your way isn't the only way.

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

I've rethought this a little and now think I can make some use of 
HGPLAIN.  Namely, in those occasions when I'm extracting data to 
construct one of my tables, trees, etc. and don't really need to care 
about the users configuration.

However, where the commands are being used to make changes to the 
repository or the source files I have to respect the users configuration 
choices including the localization of any output that the command may 
omit.  I think that the only one I really have to worry about here is 
the pager (which waits for user input) and I can control that with --pager.

But I'm not going to worry about this until I get user complaints.

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

I just tried this to see what would happen and it says:

diff: unrecognized option '--color=always'

and:

hg help | grep color

returns an empty string.  Same happens with 'colour' (real English 
spelling) instead of 'color' (American English spelling).

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

A "dumb" terminal has no concept of colour and I'm pretty sure that 
somewhere in the code chain (probably in the libraries: C or Python) the 
sending of colour information gets stripped out so that the user using a 
dumb terminal doesn't get a huge jumble of rubbish.

If this isn't the case, then the user will have to change his 
configuration or not use gwsmhg.  Their choice.

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

I'm quite calm as can be determined by the absence of an adverse review 
of "Mercurial: the Definitive Guide" on the O'Reilly site.

Peter
PS As I said I'll build my own tool.  That's the recommended to get the 
interface that you want.  As opposed to ripping up someone else's 
perfectly good interface.


More information about the Mercurial-devel mailing list