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

Augie Fackler durin42 at gmail.com
Thu Nov 25 23:49:56 CST 2010


On Nov 25, 2010, at 11:26 PM, Peter Williams wrote:

> On 26/11/10 13:44, Augie Fackler wrote:
>> 
>> On Nov 25, 2010, at 7:27 PM, Peter Williams wrote:
>> 
>>> On 26/11/10 02:18, Dan Villiom Podlaski Christiansen wrote:
>>>> On 25 Nov 2010, at 06:43, Peter Williams wrote:
> [...]
>> 
>>> 
>>>> We all
>>>> agreed that this was sorely needed. As part of this effort, the qsave,
>>>> qrestore, qinit and qcommit commands were deprecated.
>>> 
>>> qcommit?  I won't use this as I've never used it except for some trials (and had to run help to remind myself what it was). I found version control of the patches to be overkill and not worth the effort.  I found that making a gzipped tar of the patches directory was a much easier way to keep a history of the patches.
>>> 
>>> Taking away qinit will mean the MQ can no longer be used as a stand alone (i.e. on a source tree that isn't under Mercurial control) patch manager.  Still you don't care about other users do you?
>> 
>> How has mq *ever* worked on a tree that wasn't under hg control? I don't see how that's even possible. Perhaps you mean on a patch queue not under hg control?
> 
> Very well as it turns out thanks to the original designers forethought and excellent design.

I'm still not sure what your use case is here - are you claiming that it works fine when .hg/patches is not an hg repo (still true, tho we've deprecated some of that functionality, but (speaking for myself, at least) would love to hear from active users of qsave/qrestore/etc and learn why that's preferred over having .hg/patches be a repo. Perhaps we should better-document qsave/qrestore and un-deprecate them, but that's not a decision we can easily make without more help from those that actually use the features) or something else?

[...]

>>> On the subject of stand alone use of MQ, it's quite useful in this role and, although both it and quilt have their faults, is in fact better than queue (IMHO) but only because of the availability of the -qsave dance for merging the patches in after a source tree update.  I even added support for it as an alternative back end (to quilt) in gquilt (my PyGTK GUI for quilt).  I used to use it to manage Linux kernel patches on top of CVS, bitkeeper and git (although towards the end I used to convert git kernel repositories into Mercurial to leverage the extra synergy when MQ is used on top of Mercurial).  After the initial conversion it's pleasingly easy to keep a Mercurial conversion of a git repository up to date (well done 'convert' authors).
>>> 
>>> I've never used qrestore as I only use qsave to do the update dance but it's a natural pair to qsave.
>>> 
>>> Personally, I think the only justification for removing functionality is that it's becoming too expensive to maintain or is buggy.  That no developers use the functionality is certainly not a valid reason.
>> 
>> Perhaps you could (calmly) explain your use case for qsave and qrestore more clearly, and be open to us not understanding why you don't want to directly use hg to manage the history of the patches.
> 
> The fact that I say that I find them useful should be sufficient.  It costs nothing to leave them there.

That's completely untrue. All software functionality has a maintenance burden, and that burden gets higher the less well the need for the feature is understood. Thus my request for your use case so I can *understand* what you want here.

[...]

>>>> The two first
>>>> because no-one present understood them.
>>> 
>>> What about people who weren't there?  Don't you have any consideration for your users.  Did you think about reading the documentation or consulting MQ's original author?
>> 
>> MQ's documentation has honestly always felt a bit thin, and the majority of those that have actually done major work on MQ since its inception were at the sprint.
>> 
>> [...]
> 
> The key part of your statement is "done major work on MQ".  The ones who matter are the users who've "done major work with MQ".  More indication of your selfishness and lack of consideration of users.

I use MQ daily, as do most of the crew members I know.

Also: please drop this selfishness claim - it's not getting anything done, and only offending some people. I'm *trying* to understand your distress here, but the longer this thread continues the harder it is (for me at least) to understand the actual functionality you want in a meaningful way so we can come up with something that'd be suitable to everyone involved. Just yelling at us that we removed a feature you loved doesn't really help, but telling us the details of the *why* is more helpful.

Would it be helpful if there was a --empty flag for qnew that would only create a patch if it'd be empty upon creation?

Would it be alright if instead of a flag, that was a configuration option (no name springs to mind at present) in the [mq] section of hgrc?

Perhaps we should make qnew print a note when a new patch is created non-empty? Would that be enough (since you can qpop and qfold if needed)?

How do others feel about such functionality? I'm somewhat loathe to add config knobs, but at the same time I really do understand the user's frustration here.

>>>> A much more
>>>> fruitful topic would — in my opinion — be how we can minimise the pain
>>>> for the one user — so far — that was bit by this change. The way I see
>>>> it, there are two ways to deal with this:
>>>> 
>>>> 1) Add a flag that would be the reverse of what --force used to do.
>>> 
>>> That would be good.
>>> 
>>> I'm not so much mad about -f behaviour being the default as I am about the removal of the ability to protect against forgotten qrefreshes.
>> 
>> I can see why you'd feel strongly about this - for my part, I can understand the desire for the old behavior even if I personally find the old behavior annoying. That said, I think 2 is better than 1 because we're *actively* discouraging use of [defaults],
> 
> At last, an admission that your way isn't the only way.
> 
>> 

[...]

> 
>> 
>>> [...]
>>>> 
>>>>> In any case, the --pager option enables this feature to be turned off
>>>>> when a command is run so this extension shouldn't cause gwsmhg any
>>>>> problems (after I make the necessary changes).
>>>> 
>>>> So, what if someone has aliased ‘diff’ to ‘diff --color=always’?
> 
> I just tried this to see what would happen and it says:
> 
> diff: unrecognized option '--color=always'
> 
> and:
> 
> hg help | grep color
> 
> returns an empty string.  Same happens with 'colour' (real English spelling) instead of 'color' (American English spelling).

--color comes from the color extension.

[...]

>> I'm sorry this is so frustrating for you. I'd love to have everyone calm down and see if we can't come up with some kind of solution that's workable for everyone (that is: keeps the common-case behavior while still making it reasonably easy to get the "safer" old behavior.)
>> 
> 
> I'm quite calm as can be determined by the absence of an adverse review of "Mercurial: the Definitive Guide" on the O'Reilly site.
> 
> Peter
> PS As I said I'll build my own tool.  That's the recommended to get the interface that you want.  As opposed to ripping up someone else's perfectly good interface.

I'd like to try and come up with an approach that can satisfy at least more of our users, if you're willing to try and help me understand *what* you want to do rather than just insist that we can never change.



More information about the Mercurial-devel mailing list