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

[Peter Williams]

On 24/11/10 23:10, Martin Geisler wrote:
> Peter Williams<pwil3058 at bigpond.net.au>  writes:
>
>> On 23/11/10 19:33, Martin Geisler wrote:
>>> Peter Williams<pwil3058 at bigpond.net.au>   writes:
>>>
>>>> But qnew without -f doesn't do what it always did. By having qnew -f
>>>> fail you're alerting the user to the fact that something has
>>>> changed.
>>>
>>> It does not fail here -- the flag is accepted. The qnew command now
>>> behaves as if -f is always passed.
>>
>> That's my point. I'm very surprised that you don't see it as a problem
>> that the behaviour of qnew WITHOUT -f is now different to what it used
>> to be and that (other than the help page which is, quite frankly, an
>> inadequate conduit for informing the user of such a significant
>> change) it is silent.
>
> I don't see the change in 'hg qnew' as a problem since it improved the
> command: 100% of the time I ran 'hg qnew' I really meant 'hg qnew -f'.
>
> I know we changed behavior -- I just think it was for the better.

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?

>
>> You've basically reduced the flexibility available to the user by this
>> change. You could restore the flexibility by adding a flag that could
>> be used to give the original qnew (without -f) behaviour.
>
> I suggest calling 'hg status -mar' first if you want to check for
> modifications. I can see you already fixes this in your front-end:
>
>    http://gwsmhg.hg.sourceforge.net/hgweb/gwsmhg/gwsmhg/rev/75175e8b9e42
>
> Judging from the commit message you were not happy about this change...
> This kind of decoupling makes it possible for us to gradually evolve the
> underlying tool when we find better ways of doing things, and you still
> have to option of wrapping things nicely like you did. That doesn't seem
> so bad to me.

You haven't found a better way to do things. You've scratched a personal 
itch.  In the process, you've scratched everybody even those that 
weren't itching.

>
>>> I think you are one out of only a handful of people who understand
>>> how qsave works :) I'm much more happy about using rebase to make a
>>> patch queue apply on tip after a pull.
>>
>> I think that rebase is a good replacement but it's buggy. Or at least
>> I've received no notification that the bug report that I raised on it
>> (which makes it unusable with MQ without the risk compromising (local
>> and remote) repository integrity) has been fixed.
>
> I'm afraid you will have to be more precise here. I went to the bug
> tracker to search for bugs opened by you -- I found a 'PeterW' user
> there who had reported two bugs, but none of them was about rebase.
>
>>>> Hopefully, Mercurial's main functionality will hold no surprises in
>>>> the future.
>>>
>>> You must agree that we've kept Mercurial *very* backwards compatible.
>>
>> Sorry, I can't agree with that. What's more some of the breaches of
>> backward compatibility are gratuitous (with no compelling rationale).
>>
>> There seems to be an attitude that "I don't use this feature so it
>> should be removed." is an adequate rationale amongst some.
>
> It's more like "we don't use/understand this feature and there are
> better alternatives -- let's deprecate the old feature". We do this so
> that users can keep using their old scripts, but still transfer to new
> and better workflows.

"Your workflow" doesn't necessarily equal "better workflow" except for 
you.  You're trying to dictate other peoples workflows by removing 
alternatives that aren't necessary for your workflow.  That's not progress.

>
> Notice that when we talk about backwards compatibility, then we want to
> make sure that your script can still call the same commands and get the
> same results if they succeed.

Well that id no longer true for "hg qnew" (but is for "hg qnew -f"). 
Can't you see that that is a serious break in backward compatibility.

>
> In this case, 'hg qnew' would fail before and succeed now -- a script
> should call 'hg status -mar' before calling 'hg qnew' if there was a
> chance the working copy was dirty.

This just isn't about scripts.  What about the command line user who 
forgets to do a "hg qrefresh" before doing a "hg qnew".  The "hg qnew" 
succeeds silently and adds the uncommitted changes to the new patch and 
the user is completely unaware this has happened.

This is not a user friendly scenario.

I was lucky when it happened to me because I was using gwsmhg and it 
immediately updates the patch file display after a qnew so I saw the 
files there.  At first, I thought that I had introduced a bug to 
gwsmhg's file display routines because (I foolishly thought) that 
Mercurial wouldn't have introduced backward incompatibilities without 
bumping the major version number.  How wrong I was.

>
>> At times, when I'm really cheesed off, I toy with the idea of
>> submitting a review to O'Reilly's "Mercurial" book recommending that
>> it be avoided as Mercurial developers' lack of commitment to backward
>> compatibility means that it (the book) is rapidly becoming useless. So
>> far I've managed to calm myself down before I do it.
>
> I maintain the Kick Start guides and I've had very little to adapt when
> upgrading from one version to another.

You shouldn't have to adapt anything.  Just be adding documenting new 
features.

>
>>> Personally, I would have liked to make bigger changes, but Matt has
>>> done a careful job of keeping the command line input/output stable.
>>> The -f flag for qnew may be an exception.
>>
>> I know. That's why I stopped reading the lists: the constant attempts
>> by people such as yourself to ruin a good tool were just upsetting me.
>> Matt's resistance gave me hope that I could butt out of the fray with
>> some confidence that your attempts would be thwarted. I appear to have
>> been mistaken.
>
> Well, I obviously don't agree with this :-)
>
>> All that should be happening to Mercurial is enhancement and extension
>> NOT redesign. Those who don't like the current design should create a
>> new tool that conforms to their desired design.
>
> I think we all agree on that, we just don't agree on what constitutes a
> redesign. Mercurial will continue to work like it does today, but I very
> much hope we can still fix bad UI decissions.

IMHO you're replacing GOOD UI decisions with BAD ones and, what's worse, 
for purely selfish reasons.  It's compounded by the fact that the 
default options mechanism in the configuration files provided you with a 
personal workaround.  Or has that mechanism been removed as part of the 
so called improvements.

>
>>> Are you not aware of the HGPLAIN environment variable? That is what
>>> frontends should set when driving Mercurial in the background. Please
>>> see 'hg help env'.
>>
>> No. I was not aware of that. But, having just read the details, I
>> don't think that it's a good solution as if I use that to suppress
>> localization of the texts (just so I can parse them in English) I am
>> now presenting error messages to the user in English rather than his
>> chosen language. I think that is more user unfriendly than the loss of
>> the GUI features that rely on the parsing.
>
> It's not only about parsing error messages, it'a also about turning off
> extensions such as color and pager, and turning off parsing of the
> defaults and alias config sections.

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

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.

Peter