mq: hg qnew doesn't record changes in the patch

Robin Farine robin.farine at
Wed Sep 21 09:35:45 CDT 2005

On Wed September 21 2005 15:02, Ling, Xiaofeng wrote:
> Chris Mason <> wrote:

> > In general, -f means 'I really know what I'm doing, don't do
> > extra checks'.  For qpush and qpop, it skips the check for
> > local changes (making the push or pop much faster on large
> > repos), so I'm trying to be consistent in how the flag gets
> > used.

> General speaking, I think hg qnew shall do the qrefresh by
> default. As qnew will check in the changes, I originally think it
> will do qrefresh also. but later I found it does not, so when I
> pop out the patch, the change lost.

So did I, half a day of work lost in about "real 0m0.001s" :-S which  
by the way I mention as an excuse for bugging Chris on this matter.

> So doing qrefresh by default it better, user will not lose any
> work. otherwise, maybe many users will complain the problem. 

Agreed. Now that I rethink about it, qnew's case seems quite 
different from qpush and qpop. Invoking qpush or qpop with -f may 
destroy local changes as the command is invoked, so 'I really know 
what I'm doing, don't do extra checks' makes sense.

However, with qnew -f there is no immediate risk to lose work. In 
this case, -f means currently something more like 'I want to 
include the current changes in the new patch but I will do a 
qrefresh after having hacked a bit longer' (but then I could as 
well hack now and invoke qnew later), or even 'I really know that 
if I ever need to pop this patch one day, I will first pop the 
patches above it, then do a qrefresh, and finally pop it'.

Well, not the best prose ever but hopefully sufficient to illustrate 
the point.


More information about the Mercurial mailing list