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

[Martin Geisler]

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.

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

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

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.

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.

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

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

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


-- 
Martin Geisler

aragost Trifork
Professional Mercurial support
http://mercurial.aragost.com/kick-start/