Eligible patches should get a new button in addition to Review. The new Apply button would show the text drush iq am NID-CID. The user would copy/paste that text to his shell and drush will branch, download, apply the patch. We could even do the Flash trick that Github does to quickly copy an URL to user's clipboard (see the git clone URL on a github project).
The drush_iq commands are maturing quickly and it is time to get some them into broad use. To date, dreditor has really helped with pure code review. This feature request brings dreditor full circle, encouraging folks to try out patches in addition to just code reviewing them.
Here is a dump of the available iq commands, the detail for the am command, and the general help Topic for iq.
iq commands and descriptions.5>
~/.drush/drush_iq (7.x-1.x=)$ dr --filter=iq
All commands in iq: (iq)
iq-apply-patch Look up the most recent patch attached to the specified issue, and apply it to its project.
(patch, iqa, am)
iq-branch (iqb) List branches created by iq commands and switch to or delete them.
iq-create-commit-com Create a commit comment for the specified issue number.
ment (iqccc, ccc)
iq-diff (diff, iqd) Create a diff. Uses `git format-patch`, so author information is included.
iq-info (iqi) Show information about an issue from the queue on drupal.org.
iq-merge (merge, Merge patch working branch into the original branch.
iqm)
iq-reset (reset, Stop working on a patch, and return to the original branch.
iqr)
Detail for the am command
~/.drush/drush_iq (7.x-1.x=)$ dr help am
Look up the most recent patch attached to the specified issue, and apply it to its project.
Examples:
drush iq-apply-patch 1234 Apply the newest patch attached to issue 1234.
drush iq-apply-patch 1234-#5 Apply the patch attached to the fifth comment of issue 1234.
drush iq-apply-patch 1234-5678 Apply the patch attached to comment id 5678 of issue 1234.
drush iq-apply-patch 1234 --select Show all patches attached to issue 1234, and prompt for the one to apply.
Arguments:
number The issue number.
Options:
--base When applying a patch while working in a detached HEAD state, creates a branch to serve as the base for future diffs
and merges.
--dry-run Do not apply the patch; just print out messages about what would be done.
--keep-patch Keep the patchfile after applying it. Default is to delete the patchfile.
--no-commit Create a new branch, but do not commit the patch to the issue working branch after applying it. Optional. Patches
created by git format-patch are always committed.
--no-git Do not execute any git commands. Default is to create a new branch for the issue and commit the patch.
--no-prefix Patch was created with --no-prefix, and therefore should be applied with -Np0 instead of -Np1. Optional; default is
to try both.
--select Prompt for which patch to apply. Optional; default is newest patch.
Topics:
docs-iq-commands Issue queue commands for applying and creating patches from drupal.org.
Help Topic
===== Drush Issue Queue Commands ===== Drush provides a set of commands to make interacting with the issue queue on Drupal.org easier. In particular, the workflow described by the advanced patch contributor guide ( http://drupal.org/node/1054616 ) is followed, so the patch files generated will contain information crediting the authors. The Drush issue queue commands makes it much easier for beginners, and much faster for beginning and experienced git users alike to create and apply patches. ::: Applying Patches ::: Patches can be applied with the Drush iq-apply-patch command. The Drush iq commands work best with projects that are cloned from their git repository on Drupal.org, either by following the instructions at http://drupal.org/project/project-name/git-instructions, or by using the --package-handler=git_drupalorg modifier with Drush pm-download. $ drush pm-download uuid --package-handler=git_drupalorg $ cd uuid $ drush iq-apply-patch 1236768 These commands may either be executed from within a working Drupal site, or stand-alone, just to see what the patch looks like in context. If you download the module into a working Drupal site, it is not necessary to cd to the project directory before running the ip-apply-patch command; Drush can find the project directory on its own. Once you execute these commands, Drush will go out and find the most recent patch that has been posted on the given project, and apply it using either git am or patch , as appropriate. If you do not want to apply the most recent patch, then you can append the comment number to the end of the issue id; for example, to take the patch from the seventh comment of issue 1236768: $drush iq-apply-patch 1236768-#7 Finally, you might sometimes find it convenient to specify a patch via the full URL to the issue node, like so: $drush iq-apply-patch http://drupal.org/node/1236768 This form is handy to use when viewing a project's issue queue; you may copy the issue URL to your clipboard by right-clicking on it, and then paste it into a terminal window to use with iq-apply-patch, all without needing to re-visit the issue in the browser to find the most recent patch. Before the patch is applied, Drush will create a new branch to store your changes in. This step is optional, and can be subverted by supplying the --no-git option to iq-apply-patch. By default, most iq commands do not modify the state of your repository; the automatic creation of the Drush iq branch is one exception. ::: Creating Patches ::: After testing and modifying your patch, you may wish to create a new version of the patch to post back to the issue queue. This may be done with the Drush iq-diff command. $ drush iq-diff The iq-diff command will attempt to use the git format-patch to create the patch, but if you do not desire this, the --no-git option may be used to create a simple patch instead. Note that by design, the git format-patch requires that all modified code be committed to the issue branch before it can be included in the patch. The iq-diff command will create a temporary commit to run the format-patch on, but it then immediately backs the commit out again, leaving all of your changes in an unstaged state. This is done so that the Drush iq commands can be used quickly, without worrying about accumulating unwanted commits in your iq branch. If you are a more experienced git user, and prefer to keep these commits around to show the history of the patch's development, you may retain them by specifying the --commit flag when running drush iq-diff . ::: Committing Changes ::: As previously mentioned, it is possible to commit changes to your iq branch using the --commit flag with drush iq-diff. If you would prefer to commit your changes via git directly, you may; in this instance, you might want to use the iq-create-commit-comment command to facilitate a quick commit. The iq-create-commit-comment command is aliased to ccc, so you can quickly commit via: $ git add . $ git commit -m "`drush ccc`" ::: Cleaning Up ::: When you are done with an iq branch, you may clean it up with an iq-reset command. $ drush iq-reset This will preserve your iq branch so that you may return to it later. Note that in order for this to work correctly, you must commit your unstaged changes to your iq branch first. If you do not commit, then all of your unstaged changes will come with you when you return to the previous main branch that the iq branch was split off from. This is standard git behavior, and the iq commands maintain it. If you are completely done with the iq branch, you may use the --hard option to perminently delete it. Since it is easy to re-create the branch with iq-apply-patch, it is safe to remove your iq branches after you have posted your changes as a new patch on the issue.
| Comment | File | Size | Author |
|---|---|---|---|
| #15 | i1865822-15.patch | 3.12 KB | attiks |
| #14 | dreditor-Add_new_button_Apply_beside_existing_Review_button-1865822-14.png | 33.91 KB | helmo |
| #13 | dreditor.simplytestme.13.patch | 2.33 KB | sun |
| #10 | i1865822-9.patch | 1.31 KB | attiks |
| #9 | core-2013-02-18_1410.png | 139.14 KB | yesct |
Comments
Comment #1
greg.1.anderson commentedI think this is a great idea. I'd like to expand on what Moshe said above to describe the current iq-apply-patch workflow.
Imagine that the user wants to apply the patch attached to the comment shown below:
This can be done in a few simple steps.
drush amand then [paste] [return].This sequence results in the command
drush am http://drupal.org/node/1548034#comment-6798138, which Drush iq understands. While this workflow is quick and simple, it is not very discoverable. I think that an "Apply" button would be very helpful. Ideally, the clicking the apply button would immediately copy the appropriate Drush iq command to the clipboard. I would recommend the following form:drush iq-apply-patch 1548034-#10Ideally, a dialog or pane would then be displayed showing the text that was copied to the clipboard, and giving the user basic instructions ("Open a terminal window, cd to your Drupal root and paste this command to apply the patch. Use 'drush dl drush_iq' to install the iq-apply-patch command.") I think this would help speed along folk's patching considerably.
Optionally, some "next steps" might also be displayed from the "Apply" dialog:
drush iq-diff- create a new patchdrush iq-merge && git push- merge and commit an issue branch (maintainers)drush iq-reset- stop working on a patch and move back to the upstream branchdrush iq-branch- resume working on an issue branch (prompt user to select which one)Some folks also might not realize that following this workflow (drush iq-apply-patch + drush iq-merge) automatically gives commit credit to the user who posted the patch, even if the patch was made with diff instead of format-patch. This provides a better community experience (commit credit for contributors) without any extra work. It would be great if dreditor could provide more exposure to this tool with the suggested 'apply' button.
Comment #2
lewisnymanHow about inserting a link to simplytest.me? You're now able to preset the patch field:
#1912874: Presetting the patch and additional module fields
Comment #3
attiks commentedYou mean something like this
Comment #4
attiks commentedPatch attached

Comment #5
attiks commentedBetter way to get project name
Comment #6
attiks commentedtypo fix jQuery => $
Comment #7
attiks commentedFixed the project name for drupal core :/
Comment #8
yesct commentedtested #5
but project name is not going into simplytest.me correctly.
also, hovering on the test! link shows the patch url, not that simplytest.me is about to open (nit, but would be nice. I have no idea if that is possible.)
(adding drush commandline for copy and paste would still be another button "apply"...)
Comment #9
yesct commentedtested #7
I dont know if it works with the autocomplete... human needs to pick Drupal Core,
and the version didn't get set for the patch...
Comment #10
attiks commented#8 try this please it will just output a link, using the right project name for core and contrib, including the version string
Comment #11
swentel commentedOh this is sweet - tested it on a core and a contrib project and works fine - looks ready to fly to me.
Comment #12
patrickd commented#10 works great! This is amazing :) Thank you!
Don't know whether this makes sense to be in dreditor, but being able to launch a sandbox from the releases-table of a project page would be pretty awesome too ^^
Comment #13
sun@patrickd: With this, I hope you're prepared for a massive influx of simplytest.me site instances? ;)
Thanks all, this makes a great deal of sense.
I merged the additional link/button into the existing patchReview behavior, since testing a patch live is another form of reviewing. I also excluded it for .txt attachments (typically interdiffs), renamed the button label to "simplytest.me" to be more self-descriptive, and added a target="_blank".
Thanks for reporting, reviewing, and testing! Committed and pushed.
That said, this patch should actually have been done in a separate issue, since it isn't exactly what is being requested in the OP. ;)
Thus, reverting back to active. :)
Comment #14
helmo commentedThis unfortunately has a regression on the issue listing page: http://drupal.org/project/issues/dreditor
Comment #15
attiks commentedPatch for 'Apply' functionality and fixing regression from #14
Comment #16
lewisnymanWow for some reason i didn't get any notifications on this issue, nice work on picking it up so quickly! Technically the issue title has been fixed, just with a different implementation
Comment #17
sunre: #14: I'm sorry for that — didn't notice that due to the additional d.o unleashed user style. I've committed and pushed a fix for it, along the lines of #15.
Speaking of the other changes in #15, I'm really not sure what the best way is to expose that command line.
For the commit message widget, I intentionally chose to use a text input field, because that allows users to easily select + copy the command line.
In an ideal world, my browser would be able to communicate with my filesystem/shell and execute that command for realz... but for a dozen of obvious reasons, I doubt that this is possible in any way ;)
Comment #18
attiks commented#17 I think a command line will work for people already using this approach, but if we want the learn others to use this as well, we need some more information, but I'm open to suggestions.
+1 for controlling the command line from the browser ;-)
Comment #19
helmo commentedGreat work.
To improve the code for getting the projectname from the breadcrumb, I've added a utility function in #1294662: Suggest patchname in issue comment
The patch there also updates the code from this issue to use the same function.
Comment #20
sunTo not further "hi-jack" this issue, I've created #1921588: Improve simplytest.me integration — Feedback welcome :)
Comment #21
moshe weitzman commented@sun/helmo - the ideal way to integrate copy/paste is the new library that github uses to lets you copy/paste the url for cloning, commit ids, etc. See https://github.com/blog/1365-a-more-transparent-clipboard-button
Comment #22
sunYeah, hm. For that, we'd have to investigate browser support and compatibility of the @require and @resource user script meta properties, since we can't include a .swf file (although a base64-encoded binary data URI stream might be another option).
Comment #23
moshe weitzman commentedAnyone available to research per Sun's comment?
Comment #24
attiks commentedI just remembered that shurly has similar functionality, it might help and it doesn't need swf's
see http://drupalcode.org/project/shurly.git/blob/refs/heads/7.x-1.x:/shurly.js
Comment #25
moshe weitzman commentedLooks to me like it uses swf - http://drupalcode.org/project/shurly.git/tree/HEAD:/zeroclipboard
Comment #26
attiks commented#25 You're right, it's even the same lib as proposed in #21, I better start my weekend ;-)