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

[Peter Williams]

On 23/11/10 19:33, Martin Geisler wrote:
> Peter Williams<pwil3058 at bigpond.net.au>  writes:
>
>> On 23/11/10 05:04, Matt Mackall wrote:
>>> On Sat, 2010-11-20 at 10:41 +1000, Peter Williams wrote:
>>>> On 20/11/10 08:15, Matt Mackall wrote:
>>>>> On Fri, 2010-11-19 at 11:39 +1000, Peter Williams wrote:
>>>>>> The behaviour of qnew no longer conforms to the description on
>>>>>> page 235 of "Mercurial, The Definitive Guide" due to the removal
>>>>>> of the -f option to this command.
>>>>>
>>>>> The -f option has not been removed. In fact it's used in no fewer
>>>>> than 24 places in our test suite. It's simply been deprecated.
>>>>
>>>> Since the old -f behaviour is now the default deprecating it and
>>>> leaving it there is worse than removing it.
>>>
>>> No, leaving it there avoids needlessly breaking tools that expect the
>>> -f switch to exist. qnew -f does what it's always done.
>>
>> 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.

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.

>
>> [...] The only advantage that MQ had over quilt was the "qsave -a"
>> dance for merging patches after a repository update which last time I
>> read the developer list was in danger of disappearing and the mooted
>> replacement was buggy (with no sign of the bugs being seriously
>> addressed).
>
> 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.

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

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.

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

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.

>
>> Peter
>> PS On the subject of third party tools, it would be nice if the error
>> return value returned on abort could contain flag values indicating
>> suggested remedies (such as "refresh and retry", "use -f to force",
>> etc).  At the moment, in gwsmhg, I parse stderr (and stdout because
>> error messages sometimes go there instead of stderr) looking for
>> various strings to get this information (and display popups offering
>> the alternatives along with buttons to make the choice) but this
>> strategy will fail in the face of i18n
>
> 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.

Peter