git-process 1.0.11 → 1.1.0

data/CHANGELOG.md

@@ -1,12 +1,39 @@
-# CHANGELOG - 1.0.9 #
-
-### Since 1.0.10 ###
-
-* Changed gemspec to use Octokit 1.22
+# CHANGELOG - 1.1.0 #
 
 ### Since 1.0.8 ###
 
+* Adds `git pull-request {repoName}/{branchNumber}` ([GH-92](https://github.com/jdigger/git-process/issues/92))
+    * If a number is given to "git-pull-request", or a number with a server preceding it (e.g., "origin/23"), then
+      this assumes that the number refers to an existing pull request identified by that number. In that case, the
+      branch associated with the HEAD of the pull request is checked out.
+* Adds `git to-master {repoName}/{branchNumber}` ([GH-94](https://github.com/jdigger/git-process/issues/94))
+    * If a number is given to "git-to-master", or a number with a server preceding it (e.g., "origin/23"), then
+      this assumes that the number refers to an existing pull request identified by that number. In that case, the
+      branch associated with the HEAD of the pull request is checked out before doing the rest of the "to-master".
+* `git new-fb` changes to work better with integration branch ([GH-99](https://github.com/jdigger/git-process/issues/99),
+  [GH-103](https://github.com/jdigger/git-process/issues/103) and [GH-105](https://github.com/jdigger/git-process/issues/105))
+* Added pull-request URL to `git pull-request` output ([GH-104](https://github.com/jdigger/git-process/issues/104))
+* Shows a cleaned up version of fetch's output. ([GH-85](https://github.com/jdigger/git-process/issues/85))
 * Changed to use HTTPS instead of HTTP by default for GitHub API usage.
+* Implementation details
+    * GitProc::PullRequest has #checkout_pull_request to checkout the HEAD branch of a pull request at any "remote"
+      that has been configured, setting the upstream to the pull request's BASE branch
+    * GitHubService module no longer uses module-level instance variables, which were causing problems with testing
+    * GitHub::PullRequest can now ask for a pull request by id
+    * Adds ability to set the upstream/tracking on a branch
+    * Upgrades to Octokit 1.24 and no longer overrides the Connection class
+      ([GH-74](https://github.com/jdigger/git-process/issues/74))
+    * Adds module GitHubTestHelper
+    * Made GitLib and AbstractMergeErrorBuilder classes instead of modules
+    * Extracted GitCofig and GitRemote out of GitLib
+    * Changed to use GitLogger as a logging fascade
+    * GitProcess now takes a GitLib instead of a directory
+    * GitHubService refactoring; includes extracting GitHubService::Configuration and GitHub::CreatePullRequest.
+    * Supports RSpec default module for GitRepoHelper. Any RSpec context can declare :git_repo_helper as metadata to get
+      standard GitRepoHelper lifecycle support as part of [GH-97](https://github.com/jdigger/git-process/issues/97).
+    * Refactored GitHubService into GitHubService::Configuration
+    * Refatored GitHub::PullRequest
+    * Refatored GitLib#branch(..) and GitLib#command(..)
 
 ### Since 1.0.7 ###
 
@@ -26,13 +53,14 @@
 
 ### Since 1.0.4 ###
 
-* Do not try to fetch/push when doing sync if there is not remote. (#70)
-* git-sync now merges in upstream changes. (#79)
-* Simplified Windows installation instructions. (#76 #77)
+* Do not try to fetch/push when doing sync if there is not remote. ([GH-70](https://github.com/jdigger/git-process/issues/70))
+* git-sync now merges in upstream changes. ([GH-79](https://github.com/jdigger/git-process/issues/79))
+* Simplified Windows installation instructions. ([GH-76](https://github.com/jdigger/git-process/issues/76),
+  [GH-77](https://github.com/jdigger/git-process/issues/77))
 
 ### Since 1.0.3 ###
 
-* Gets rid of infinate loop in Highline library. (GH-72)
+* Gets rid of infinite loop in Highline library. ([GH-72](https://github.com/jdigger/git-process/issues/72))
 
 ### Since 1.0.2 ###
 

data/Gemfile

@@ -1,7 +1,7 @@
 source "http://rubygems.org"
 
 group :default do
-  gem "octokit", "~> 1.22" # GitHub API
+  gem "octokit", "~> 1.24" # GitHub API
   gem "json", "~> 1.7.3"
   gem "trollop", "~> 1.16.2" # CLI options parser
   gem "highline", "1.6.13" # user CLI interaction. There is a bug in 1.6.14
@@ -14,6 +14,6 @@ group :development do
 end
 
 group :test do
-  gem "rspec", "~> 2.10.0"
+  gem "rspec", "~> 2.12.0"
   gem "webmock", "~> 1.8.7" # network mocking
 end

data/Gemfile.lock

@@ -1,36 +1,36 @@
 GEM
   remote: http://rubygems.org/
   specs:
-    addressable (2.3.2)
+    addressable (2.3.4)
     crack (0.3.2)
     diff-lcs (1.1.3)
-    faraday (0.8.5)
+    faraday (0.8.7)
       multipart-post (~> 1.1)
     faraday_middleware (0.9.0)
       faraday (>= 0.7.4, < 0.9)
-    hashie (1.2.0)
+    hashie (2.0.3)
     highline (1.6.13)
-    json (1.7.6)
-    multi_json (1.5.0)
-    multipart-post (1.1.5)
+    json (1.7.7)
+    multi_json (1.7.2)
+    multipart-post (1.2.0)
     netrc (0.7.7)
-    octokit (1.22.0)
+    octokit (1.24.0)
       addressable (~> 2.2)
       faraday (~> 0.8)
       faraday_middleware (~> 0.9)
-      hashie (~> 1.2)
+      hashie (~> 2.0)
       multi_json (~> 1.3)
       netrc (~> 0.7.7)
     rake (0.9.6)
     redcarpet (2.1.1)
-    rspec (2.10.0)
-      rspec-core (~> 2.10.0)
-      rspec-expectations (~> 2.10.0)
-      rspec-mocks (~> 2.10.0)
-    rspec-core (2.10.1)
-    rspec-expectations (2.10.0)
+    rspec (2.12.0)
+      rspec-core (~> 2.12.0)
+      rspec-expectations (~> 2.12.0)
+      rspec-mocks (~> 2.12.0)
+    rspec-core (2.12.2)
+    rspec-expectations (2.12.1)
       diff-lcs (~> 1.1.3)
-    rspec-mocks (2.10.1)
+    rspec-mocks (2.12.2)
     trollop (1.16.2)
     webmock (1.8.11)
       addressable (>= 2.2.7)
@@ -43,10 +43,10 @@ PLATFORMS
 DEPENDENCIES
   highline (= 1.6.13)
   json (~> 1.7.3)
-  octokit (~> 1.22)
+  octokit (~> 1.24)
   rake (~> 0.9.2)
   redcarpet (~> 2.1.1)
-  rspec (~> 2.10.0)
+  rspec (~> 2.12.0)
   trollop (~> 1.16.2)
   webmock (~> 1.8.7)
   yard (~> 0.8.2.1)

data/README.md

@@ -1,8 +1,8 @@
-[![Build Status](https://secure.travis-ci.org/jdigger/git-process.png)](http://travis-ci.org/jdigger/git-process)
+[![Build Status](https://travis-ci.org/jdigger/git-process.png?branch=master)](https://travis-ci.org/jdigger/git-process)
 
 # Purpose #
 
-This provides an easy way to work with a sane git workflow process that encourages using highly-focussed branches to encourage collaboration, enable fearless changes, and improve team communication.
+This provides an easy way to work with a sane git workflow process that encourages using highly-focused branches to encourage collaboration, enable fearless changes, and improve team communication.
 
 See the F.A.Q. for a much more complete explanation for the thoughts and assumptions that motivates this project.
 
@@ -25,7 +25,7 @@ Some older operating systems (such as OSX 10.6) are using an old version of Ruby
 
 ## Anticipated Use Cases ##
 
-1. User creates new local branch for focussed work.
+1. User creates new local branch for focused work.
 1. User pushes local branch to remote (as feature branch) by merging/rebasing with the integration branch, then pushing to the branch to remote.
 1. User closes local branch by rebasing integration branch first, then pushing local to integration.
 1. User initiates GitHub "pull request" to ease collaboration.
@@ -35,7 +35,7 @@ Some older operating systems (such as OSX 10.6) are using an old version of Ruby
 * `git new-fb` - Create a new feature branch based on the integration branch.
 * `git sync` - Gets the latest changes that have happened on the integration branch, then pushes your changes to a "private" branch on the server.
 * `git pull-request` - Creates a Pull Request for the current branch.
-* `git to-master` - Rebase against the integration branch, then pushes to it.
+* `git to-master` - Rebase against the integration branch, then pushes to it. Knows how to deal "intelligently" with pull-requests.
 
 **All commands are well documented within themselves: Use the "-h" switch to see the full documentation.** (e.g., "`git sync -h`")
 
@@ -52,10 +52,16 @@ _The following assumes that the integration branch is "origin/master"._
    as save your work on the server, do "`git sync`".
     * That will merge in the changes that have occurred in "`origin/master`" and then push the
       result to the "`feature_branch`" branch to the server.
-3. When you feel your work is ready for others to look at, do another "`git sync`" to post your
-   changes to the server, and then "`git pull-request`" to ask someone to review your changes.
-4. If you get the thumbs up from the code-review, use "`git to-master`".
+3. When you feel your work is ready for others to look at, do "`git pull-request`" to ask someone to review your changes.
+    * If no name or number is provided, it is assumed that you want to create a new pull request with the same name as the current branch.
+    * Any changes you make via "`git sync`" are automatically reflected in the pull request.
+4. As a reviewer, to see a pull-request, do "`git pull-request ##`" (where "##" is the pull request number) to check
+   out the branch associated with the pull request in your repository.
+5. If you get the thumbs up from the code-review, use "`git to-master`".
     * This will merge and push your changes into "`origin/master`", closing the pull request.
+    * If reviewing the pull request via the web interface was sufficient, or there is otherwise not a reason
+      to explicitly checkout the branch first, you can use "`git to-master`" with the pull request number to
+      combine both of these steps.
 5. If you still need to make changes, do so and use "`git sync`" to keep your branch on the
    server for that feature updated with your work until all issues have been resolved.
 
@@ -119,6 +125,7 @@ $ git to-master              # 6
 * If you want to use a different integration branch other than "`master`", set the "`gitProcess.integrationBranch`" configuration value. (e.g., "`git config gitProcess.integrationBranch my-integ-branch`")
 * This tries to respond "intelligently" to the use of 'rerere'.
 * By default the first server name reported by `git remote` is used as the server/remote name. Since most projects only have a single remote (i.e., "origin") this works most of the time. But if you have multiple remotes and want to explicitly set it, use the `gitProcess.remoteName` configuration option.
+* `git pull-request` shows the URL for the pull request after creating it on the server. Most terminal programs let you click on it to open it in your browser. (e.g., Cmd-Click on OSX.)
 
 
 # F.A.Q. #

data/bin/git-new-fb

@@ -1,10 +1,17 @@
 #!/usr/bin/env ruby
 
+#require "rubygems"
+#require "bundler/setup"
+#$LOAD_PATH.unshift File.join(File.dirname(__FILE__), '../lib')
+
 require 'git-process/git_process_options'
 require 'git-process/new_fb'
+require 'git-process/git_lib'
+include GitProc
+
 
 class NewFeatureBranchOptions
-  include GitProc::GitProcessOptions
+  include GitProcessOptions
 
   def summary
     "Create a new feature branch based on the integration branch."
@@ -47,4 +54,5 @@ DESC
 
 end
 
-GitProc::NewFeatureBranch.new('.', NewFeatureBranchOptions.new.parse_cli(File.basename(__FILE__), ARGV)).run
+opts = NewFeatureBranchOptions.new.parse_cli(File.basename(__FILE__), ARGV)
+NewFeatureBranch.new(GitLib.new('.', opts), opts).run

data/bin/git-pull-request

@@ -1,14 +1,20 @@
 #!/usr/bin/env ruby
 
+#require "rubygems"
+#require "bundler/setup"
+#$LOAD_PATH.unshift File.join(File.dirname(__FILE__), '../lib')
+
+require 'git-process/git_lib'
 require 'git-process/pull_request'
 require 'git-process/git_process_options'
+include GitProc
 
 class PullRequestOptions
-  include GitProc::GitProcessOptions
+  include GitProcessOptions
 
 
   def summary
-    "Creates a Pull Request for the current branch."
+    "Creates or gets a Pull Request."
   end
 
 
@@ -16,13 +22,21 @@ class PullRequestOptions
     <<DESC
 DESCRIPTION
 
-This creates a Pull Request on the GitHub server associated with the current \
+This creates or gets a Pull Request on the GitHub server associated with the current \
 branch. For the reasons why Pull Requests are useful for the development process, \
 see https://help.github.com/articles/using-pull-requests
 
 The "git pull-request" command is a nice, simplified alternative to using the \
 web interface.
 
+If no name or number is provided, it is assumed that you want to create a new \
+pull request with the same name as the current branch.
+
+If a number is given, or a number with a server preceding it (e.g., "origin/23"), \
+then this assumes that the number refers to an existing pull request identified \
+by that number. In that case, the branch associated with the HEAD of the pull \
+request is checked out.
+
 EXAMPLE
 
 You've been developing your killer new feature or bug fix, and you want \
@@ -53,7 +67,7 @@ DESC
 
 
   def usage(filename)
-    "Usage: #{filename} [ options ] pull_request_title"
+    "Usage: #{filename} [ options ] [pull_request_title | server/pull_request_number | pull_request_number]"
   end
 
 
@@ -75,9 +89,19 @@ DESC
 
 
   def post_parse(opts, argv)
-    opts[:title] = argv.shift
+    arg = argv.shift
+    if /^\d+$/ =~ arg
+      opts[:prNumber] = arg
+    elsif /^(.*)\/(\d+)$/ =~ arg
+      m = /^(.*)\/(\d+)$/.match(arg)
+      opts[:server] = m[1]
+      opts[:prNumber] = m[2]
+    else
+      opts[:title] = arg
+    end
   end
 
 end
 
-GitProc::PullRequest.new('.', PullRequestOptions.new.parse_cli(File.basename(__FILE__), ARGV)).run
+opts = PullRequestOptions.new.parse_cli(File.basename(__FILE__), ARGV)
+GitProc::PullRequest.new(GitLib.new('.', opts), opts).run

data/bin/git-sync

@@ -6,10 +6,11 @@
 
 require 'git-process/git_process_options'
 require 'git-process/sync'
+require 'git-process/git_lib'
 
 
 class SyncOptions
-  include GitProc::GitProcessOptions
+  include GitProcessOptions
 
 
   def summary
@@ -60,6 +61,7 @@ DESC
   end
 
 
+  #noinspection RubyUnusedLocalVariable
   def post_parse(opts, argv)
     opts[:force] = true if opts[:rebase]
     opts[:merge] = !opts[:rebase]
@@ -67,4 +69,5 @@ DESC
 
 end
 
-GitProc::Sync.new('.', SyncOptions.new.parse_cli(File.basename(__FILE__), ARGV)).run
+opts = SyncOptions.new.parse_cli(File.basename(__FILE__), ARGV)
+GitProc::Sync.new(GitLib.new('.', opts), opts).run

data/bin/git-to-master

@@ -1,7 +1,13 @@
 #!/usr/bin/env ruby
 
+require "rubygems"
+require "bundler/setup"
+$LOAD_PATH.unshift File.join(File.dirname(__FILE__), '../lib')
+
 require 'git-process/git_process_options'
 require 'git-process/rebase_to_master'
+require 'git-process/git_lib'
+
 
 class ToMasterOptions
   include GitProc::GitProcessOptions
@@ -39,28 +45,53 @@ everything is done on a feature branch.  In addition to being a much \
 safer and more flexible way of working in general, it is also a \
 requirement to take advantage of Pull Request functionality.
 
-By default the first server name reported by 'git remote' is used as the server/remote name. \
-Since most projects only have a single remote (i.e., "origin") this works most of the time. \
-But if you have multiple remotes and want to explicitly set it, use the \
-'gitProcess.remoteName' configuration option.
+By default the first server name reported by 'git remote' is used as the \
+server/remote name. Since most projects only have a single remote (i.e., \
+"origin") this works most of the time. But if you have multiple remotes and \
+want to explicitly set it, use the 'gitProcess.remoteName' configuration option.
+
+If a number is given, or a number with a server preceding it (e.g., \
+"origin/23"), then this assumes that the number refers to an existing pull \
+request identified by that number. In that case, the branch associated with \
+the HEAD of the pull request is checked out before doing the rest of the \
+"to-master".
 
-EXAMPLE
+EXAMPLE WITHOUT PULL REQUEST
 
-Assuming that the current branch is called "interesting_changes" and the integration \
-branch on the server is "master", typing "git to-master" will do roughly the following \
-for you:
+Assuming that the current branch is called "interesting_changes" and the \
+integration branch on the server is "master", typing "git to-master" will do \
+roughly the following for you:
   $ git fetch -p
   $ git rebase origin/master
   $ git push origin interesting_changes:master
-  # close pull request
+  # close pull request if one exists
   $ git checkout -b _parking_ origin/master
   $ git branch -d interesting_changes
-  $ git push origin :interesting_changes
+  $ git push origin --delete interesting_changes
 
 If you use the --interactive option, then it does an interactive rebase before the first "push".
 
 If you use the --keep option, then the process stops after the first "push".
 
+
+EXAMPLE WITH PULL REQUEST
+
+Assuming that the pull request number is 493, its branch name is "interesting_changes" \
+and the integration branch on the server is "master", typing "git to-master 493" will \
+do roughly the following for you:
+  $ git fetch -p
+  # looks up the information for pull-request 493
+  $ git checkout -b interesting_changes origin/interesting_changes
+  $ git rebase origin/master
+  $ git push origin interesting_changes:master
+  # close pull request
+  $ git checkout -b _parking_ origin/master
+  $ git branch -d interesting_changes
+  $ git push origin --delete interesting_changes
+
+If you would like the review the changes locally first, use "git pull-request 493"
+instead.
+
 NOTES
 
 * If you want to use a different integration branch other than "master",
@@ -70,6 +101,10 @@ NOTES
 DESC
   end
 
+  def usage(filename)
+    "Usage: #{filename} [ options ] [server/pull_request_number | pull_request_number]"
+  end
+
 
   def extend_opts(parser)
     parser.opt :keep, "Don't do any \"cleanup.\" It keeps the current local "+
@@ -78,6 +113,22 @@ DESC
     parser.opt :interactive, "Do an interactive rebase before pushing to the server.", :short => :i, :default => false
   end
 
+
+  def post_parse(opts, argv)
+    arg = argv.shift
+    if /^\d+$/ =~ arg
+      opts[:prNumber] = arg
+    elsif /^(.*)\/(\d+)$/ =~ arg
+      m = /^(.*)\/(\d+)$/.match(arg)
+      opts[:server] = m[1]
+      opts[:prNumber] = m[2]
+    else
+      # "normal" to-master
+    end
+  end
+
 end
 
-GitProc::RebaseToMaster.new('.', ToMasterOptions.new.parse_cli(File.basename(__FILE__), ARGV)).run
+opts = ToMasterOptions.new.parse_cli(File.basename(__FILE__), ARGV)
+#GitProc::RebaseToMaster.new(GitLib.new('.', opts), opts).run
+puts opts.inspect

data/git-process.gemspec

@@ -1,24 +1,24 @@
 require File.expand_path('../lib/git-process/version', __FILE__)
 
-gemspec = Gem::Specification.new do |gem|
-  gem.authors       = ["Jim Moore"]
-  gem.email         = ["moore.jim@gmail.com"]
-  gem.description   = %q{A set of scripts to make working with git easier and more consistent}
-  gem.summary       = %q{A set of scripts for a good git process}
-  gem.homepage      = "http://jdigger.github.com/git-process/"
-  gem.license       = 'ASL2'
+Gem::Specification.new do |gem|
+  gem.authors = ["Jim Moore"]
+  gem.email = %w(moore.jim@gmail.com)
+  gem.description = %q{A set of scripts to make working with git easier and more consistent}
+  gem.summary = %q{A set of scripts for a good git process}
+  gem.homepage = "http://jdigger.github.com/git-process/"
+  gem.license = 'ASL2'
 
-  gem.add_dependency "octokit", "~> 1.22.0" # GitHub API
+  gem.add_dependency "octokit", "~> 1.24" # GitHub API
   gem.add_dependency "json", "~> 1.7.3"
   gem.add_dependency "trollop", "~> 1.16.2" # CLI options parser
   gem.add_dependency "highline", "1.6.13" # user CLI interaction. There is a bug in 1.6.14
 
-  gem.files         = `git ls-files`.split($\).delete_if{|f| f =~ /^\./}
-  gem.executables   = gem.files.grep(%r{^bin/}).map{ |f| File.basename(f) }
-  gem.test_files    = gem.files.grep(%r{^(test|spec|features)/})
-  gem.name          = "git-process"
-  gem.require_paths = ["lib"]
-  gem.version       = GitProc::Version::STRING
-  gem.platform      = Gem::Platform::RUBY
+  gem.files = `git ls-files`.split($\).delete_if { |f| f =~ /^\./ }
+  gem.executables = gem.files.grep(%r{^bin/}).map { |f| File.basename(f) }
+  gem.test_files = gem.files.grep(%r{^(test|spec|features)/})
+  gem.name = "git-process"
+  gem.require_paths = %w(lib)
+  gem.version = GitProc::Version::STRING
+  gem.platform = Gem::Platform::RUBY
   gem.required_ruby_version = '>= 1.8.7'
 end