search

robfig / rietveld

Automatically exported from code.google.com/p/rietveld
Apache License 2.0
0 stars 1 forks source link

Support patch upload from mercurial queue #262

Open GoogleCodeExporter opened 9 years ago

GoogleCodeExporter commented 9 years ago 
What steps will reproduce the problem?
1.Create a MQ patch
2.Try to figure out the combination of shortcuts for upload.py to send the 
patch for review

What is the expected output? What do you see instead?
Diff for the current MQ patch can be receved with 'hg qdiff' command. However, 
it works only for current patch.

Original issue reported on code.google.com by techtonik@gmail.com on 13 Jan 2011 at 12:36

GoogleCodeExporter commented 9 years ago 
I believe this can be done by creating multiple patchsets for one issue, and 
using instead multiple issues to track different versions of the same patchset. 
 It is a bit different from the usual way you're supposed to use rietveld.  
This was suggested to me by a Googler, at least. :)

However, you'll probably encounter issue 267 and possibly issue 268 when trying 
to do this.

Original comment by paolo.bo...@gmail.com on 27 Jan 2011 at 4:27

GoogleCodeExporter commented 9 years ago 
That sounds interesting and uploading multiple issues matches with my 
understanding of Mercurial's patch queues. Intersted in contributing a patch?

Original comment by albrecht.andi on 27 Jan 2011 at 7:39

GoogleCodeExporter commented 9 years ago 
A patch to upload.py?

Original comment by paolo.bo...@gmail.com on 28 Jan 2011 at 8:23

GoogleCodeExporter commented 9 years ago 
Yeah, the Mercurial backend in upload.py is the only place where we can deal 
with patch queues. It seems that the mq extension is widely used in the 
Mercurial world, so supporting patch queues is a reasonable feature IMO.

Original comment by albrecht.andi on 28 Jan 2011 at 9:37

GoogleCodeExporter commented 9 years ago 
The same should be done with git then.  However, I am afraid that without some 
more specific user interface the number of issues created can be unmanageable.  
For many Mercurial and git projects it is quite common to submit patches a 
dozen at a time.

Original comment by paolo.bo...@gmail.com on 28 Jan 2011 at 12:14

GoogleCodeExporter commented 9 years ago 
(In the process of learning MQs)

My opinion is that upload.py should simply use "hg qdiff" when available.

Original comment by maruel@chromium.org on 21 Sep 2011 at 4:26

GoogleCodeExporter commented 9 years ago 
It is convenient to organize patches into trees regardless of MQ support. 
Consider scenario when overly huge patches stay in queue for too long just 
because nobody can deal with complexity. In this way a patch can be split into 
queue of patches that is possible to review separately.

When we can construct such "review trees" - we can tie MQ patches to them 
(extension or script - doesn't matter). As MQ patches can move relatively to 
each other, we will need a way to identify patch to find an issue for it when 
it moved or renamed.

Original comment by techtonik@gmail.com on 22 Sep 2011 at 4:46

GoogleCodeExporter commented 9 years ago 
What is the incantation sequence of commands to use upload.py when you've got 
your patch ready via "hg qdiff" today?

I'd love for upload.py to support at the very least that simple common case.

Original comment by gpsm...@gmail.com on 3 Feb 2012 at 9:20

GoogleCodeExporter commented 9 years ago 
Can't you use --rev rev1:rev2 ? Or is the problem that you have no way to 
figure out what rev1 and rev2 are?

Original comment by gvanrossum@gmail.com on 3 Feb 2012 at 9:48

GoogleCodeExporter commented 9 years ago

Original comment by albrecht.andi on 6 Apr 2012 at 7:19

GoogleCodeExporter commented 9 years ago 
I dug the solution and posted to 
http://code.google.com/p/rietveld/wiki/FAQ?ts=1372672996&updated=FAQ#How_can_I_u
pload_a_patch_from_Mercurial_Queue but it is very-very hard to find.

Original comment by techtonik@gmail.com on 1 Jul 2013 at 10:09