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

[Martin Geisler]

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.

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

> Hopefully, Mercurial's main functionality will hold no surprises in
> the future.

You must agree that we've kept Mercurial *very* backwards compatible.
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.

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

-- 
Martin Geisler

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