mq: hg qnew doesn't record changes in the patch
Robin Farine
robin.farine at terminus.org
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.
Robin
More information about the Mercurial
mailing list