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

Peter Williams pwil3058 at bigpond.net.au
Mon Nov 22 19:27:16 CST 2010


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.

>
>>> We had a long discussion about whether the -f behavior was actually
>>> useful last February and found that -f was almost universally a
>>> hindrance, to the point that everyone who used it used -f ALWAYS, thus
>>> nullifying it.
>>
>> Not everyone who uses Mercurial is on the mail list.
>
> Nor were they at the sprint in Paris where this was discussed.

Indeed.

>
>> PS I've modified gwsmhg to work around this change.
>> PPS What happened to the doctrine of maintaining backward compatibility?
>
> We're not perfect. Sometimes we'll perceive behaviors as bugs (which are
> not covered by the doctrine) which other folks perceive as a feature.
> Mostly we err in the other direction.
>

But backward compatibility is important.

I'll probably modify gwsmhg to enable quilt to be used in lieu of MQ for 
patch management as I no longer have confidence that MQ's behaviour will 
not change unexpectedly (and silently).

Quilt has other advantages (resulting from applied patches not being 
quasi commits) such as allowing changes/refreshes to non top patches 
which I quite like as well.  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).  Now that quilt has a snapshot function it may be 
possible to leverage that to obtain an equivalent to the dance (yet to 
be investigated) so the end result will probably be better functionality 
for the user.

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

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 making gwsmhg less user friendly. It's not 
a fatal problem just a user friendliness one.


More information about the Mercurial-devel mailing list