[PATCH] mq: Add a new command, 'qrebase', to obviate need for 'qsave'

Christian Boos cboos at neuf.fr
Mon Aug 24 12:25:03 CDT 2009


Christian Boos wrote:
> Dirkjan Ochtman wrote:
>   
>> On Mon, Aug 24, 2009 at 14:49, Peter Williams<pwil3058 at bigpond.net.au> wrote:
>>   
>>     
>>> It makes it user friendly and it makes it part of mq.
>>>     
>>>       
>> It also adds another command you have to know how to use. If the new
>> command provides little value, I don't think that's necessarily
>> userfriendly.
>>   
>>     
>
> OTOH, how many people knew that rebase worked well with MQ patches? 

... and I assumed that would be the case by reading recent messages in 
the mailing list.

However, when I played a bit with rebase and MQ patches, it seems that 
rebase has conflicts in situations where a simple qpop/update/qpush 
would have worked.

Example session:

I create a test 'file' containing one line as rev 0, then add a second 
line, make that rev 1.
Then I create two simple patches on top of rev 0, the first inserts a 
new line at the top, the second patch modifies that added line.
Rebasing those patches on rev 1 fails with a conflict on the first line.
But if I do instead a qpop -a followed by an update to rev 1, then a 
normal qpush -a will work.
I used internal:merge as the merge tool in the following session, but 
the same happens with kdiff3.

$ hg init testrebasequeue
$ cd testrebasequeue/
$ echo test > file
$ hg ci -Am 'initial version, patches will first be on top of that'
adding file
$ echo more data >> file
$ hg ci -m 'preparing target for rebase'
$ hg up 0
1 files updated, 0 files merged, 0 files removed, 0 files unresolved
$ echo some leading text > file
$ echo test >> file
$ hg qnew -f add_first_line
$ echo some leading line > file
$ echo test >> file
$ hg qnew -f modify_first_line
$ cat file
some leading line
test
$ hg diff -c modify_first_line
diff --git a/file b/file
--- a/file
+++ b/file
@@ -1,2 +1,2 @@
-some leading text
+some leading line
 test
$ hg diff -c add_first_line
diff --git a/file b/file
--- a/file
+++ b/file
@@ -1,1 +1,2 @@
+some leading text
 test
$ HGMERGE=internal:merge hg rebase --base qbase --dest 1
merging file
merging file
warning: conflicts during merge.
merging file failed!
abort: fix unresolved conflicts with hg resolve then run hg rebase 
--continue
$ hg status
M file
? file.orig
$ hg diff
diff --git a/file b/file
--- a/file
+++ b/file
@@ -1,3 +1,7 @@
+<<<<<<< local
 some leading text
+=======
+some leading line
+>>>>>>> other
 test
 more data
$ hg rebase --abort
rebase aborted
$ hg qpop -a
popping modify_first_line
popping add_first_line
patch queue now empty
$ hg up 1
1 files updated, 0 files merged, 0 files removed, 0 files unresolved
$ hg qpush -a
applying add_first_line
applying modify_first_line
now at: modify_first_line


I did some other tests, and it seems the problem happens as soon as a 
given line gets modified in more than one patch. If changes are not 
overlapping, all seems fine. I also tried without MQ by simply 
finalizing the patches, and then rebase exhibits the same behavior. So 
it's nothing specific to MQ.  rebase.py is the latest from crew. As the 
above was done on Windows, I repeated the test on a Linux machine with 
crew from today, and also with 1.3.1: always the same result.

So, did I do something wrong, or is this a serious bug/limitation in 
rebase which can't handle cumulative modifications?

-- Christian



More information about the Mercurial-devel mailing list