[PATCH] mq: do not strip revision if applied mq is descendant (issue1881)

Vishakh Harikumar vsh426 at gmail.com
Tue Jul 6 04:32:25 CDT 2010


On Mon, Jul 5, 2010 at 4:37 PM, Mads Kiilerich <mads at kiilerich.com> wrote:
>  Vishakh H wrote, On 07/05/2010 12:11 PM:
>> mq: do not strip revision if applied mq is descendant (issue1881)
>>
>> check if there are applied patches and whether strip rev is ancestor of
>> qparent or is one of applied patches. two different messages are for the
>> benefit of the user.
>
> Thanks!
>
> That would prevent the stupid user from this specific problem, but do we
> want such safety guards in the brutal and efficient strip command?

i guess not, but i put it there because we already have qpop for similar action
on mq.
another option is to cleanup the status file whenever strip removes the mq.

diff --git a/hgext/mq.py b/hgext/mq.py
--- a/hgext/mq.py
+++ b/hgext/mq.py
@@ -2408,6 +2408,18 @@
     elif rev not in (cl.ancestor(p[0], rev), cl.ancestor(p[1], rev)):
         update = False

+    q = repo.mq
+    if q.applied:
+        if rev == cl.ancestor(repo.lookup('qtip'), rev):
+            q.applied_dirty = True
+            start = 0
+            end = len(q.applied)
+            applied_list = [i.node for i in q.applied]
+            if rev in applied_list:
+                start = applied_list.index(rev)
+            del q.applied[start:end]
+            q.save_dirty()
+
     repo.mq.strip(repo, rev, backup=backup, update=update, force=opts['force'])
     return 0

> I would rather see more robust handling of inconsistencies.
>
> qapplied could check that the patches really was applied with the hash
> stored in the status file - and in the right order.
>
> The error messages could be clearer - for example by telling which patch
> caused the problem and give a hint how the problem can be resolved.
>
> What is the recommended way to resolve such an situation? Should we tell
> about the status file and expect the user to edit it manually? Or should we
> give qpop (or some other command) a way to handle the sitation?

i would prefer not to edit the status file manually, since it can be maintained
consistently in this situation.
if the above actions are enough i will send that with revised tests.

-- 
vsh


More information about the Mercurial-devel mailing list