git-process-lib 2.0.0 → 2.0.1

data/CHANGELOG.md

@@ -1,5 +1,9 @@
 # CHANGELOG - 1.2.0 #
 
+### Since 2.0.1 ###
+
+Changed git-pull-request to git-pull-req
+
 ### Since 1.1.4 ###
 
 * **Changed git-sync to default to rebasing.** ([GH-112](https://github.com/jdigger/git-process/issues/112))

data/README.md

@@ -50,7 +50,7 @@ To get full `git help` and manpage support, do:
 
 * `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 and remote feature branch, then pushes your changes to a feature branch on the server.
-* `git pull-request` - Create or get a Pull Request for the current branch.
+* `git pull-req` - Create or get a Pull Request for the current branch.
 * `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 "git help" to see the full documentation.** (e.g., "`git help sync`")
@@ -73,17 +73,17 @@ To get full `git help` and manpage support, do:
   * "`git sync`" makes it extremely easy for you to get any changes that are made in "`master`" into your branch so you can react to it immediately.
   * "`git to-master`" then makes it easy to cleanly integrate the changes you have made. If you need to keep the current branch open, use the `--keep` option. Otherwise it closes the branch along with various other house-keeping duties.
 * The process that you use should be essentially the same, regardless of whether you are working alone, or on a large distributed team.
-  * The exception here is "`git pull-request`" since you typically do not use pull requests when working solo or when pair-programming.
+  * The exception here is "`git pull-req`" since you typically do not use pull requests when working solo or when pair-programming.
 
 
 # Notes #
 
 * After publishing changes to the main integration branch (i.e., "`git to-master`") the old feature branch is removed as part of cleanup. Git is then "parked" on a "`_parking_`" branch until a new feature branch is created. Work is not expected to be done on this branch, but any that is done is brought over to a newly created feature branch (i.e., "`git new-fb`").
 * If there is a problem (such as a merge conflict), this will try to resolve such errors for you as much as it can do safely. When it can't do so in an automated way, it will try to tell you the process for doing so manually.
-* The first time you use a GitHub feature (e.g., "`git pull-request`"), this will ask for your username and password. It does not store them, but instead uses them to get an OAuth2 token, which is stored in "`git config gitProcess.github.authToken`".
+* The first time you use a GitHub feature (e.g., "`git pull-req`"), this will ask for your username and password. It does not store them, but instead uses them to get an OAuth2 token, which is stored in "`git config gitProcess.github.authToken`".
 * 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`")
 * 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.)
+* `git pull-req` 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.)
 
 
 # Workflow Examples #
@@ -178,7 +178,7 @@ He creates his "Laaaaame" class and checks it in, with a pull request asking Sal
 
 ```
 bill-[awesomo4000]$ git commit
-bill-[awesomo4000]$ git pull-request "A.W.E.S.O.M-0 4000 prototype" \
+bill-[awesomo4000]$ git pull-req "A.W.E.S.O.M-0 4000 prototype" \
                     -d "@sally, can you make sure Butters won't recognize it?"
   Pushing to 'awesomo4000' on 'origin'.
   Creating a pull request asking for 'awesomo4000' to be merged into 'master' on big_monies.
@@ -189,7 +189,7 @@ bill-[awesomo4000]$
 Sally sees the email. After looking at it in the web interface, she wants to test it.
 
 ```
-sally-[other_branch]$ git pull-request 3454
+sally-[other_branch]$ git pull-req 3454
   Getting #pr_number
   Fetching the latest changes from the server
     new branch: awesomo4000
@@ -308,25 +308,6 @@ One significant advantage of using automation like this is that it lets you have
 This project is trying to promote clear communication about reality as it applies to the code, over micro-management over no-longer-relevant history. Thus rational for the judicious use of rebase.
 
 
-# Contributing #
-
-## Coding Setup ##
-
-1. Fork it
-2. Create your feature branch (`git checkout -b my-new-feature origin/master`)
-3. Commit your changes (`git commit`)
-4. Push to the branch (`git push origin my-new-feature`)
-5. Create new Pull Request
-
-or, if using these scripts:
-
-1. Fork it
-2. `git new-fb my-new-feature
-3. `git commit`
-4. `git sync`
-5. `git pull-request`
-
-
 ## License ##
 
 Licensed under the Apache License, Version 2.0 (the "License");

data/docs/git-new-fb.1.adoc

@@ -65,7 +65,7 @@ this will remove that branch.
 SEE ALSO
 --------
 
-*git-process*(1), *git-to-master*(1), *git-sync*(1), *git-pull-request*(1)
+*git-process*(1), *git-to-master*(1), *git-sync*(1), *git-pull-req*(1)
 
 
 BUGS

data/docs/git-process.1.adoc

@@ -126,7 +126,7 @@ Meanwhile Bill has been working on his great idea:
 He creates his "Laaaaame" class and checks it in, with a pull request asking Sally to do a code review.
 
   bill-[awesomo4000]$ git commit
-  bill-[awesomo4000]$ git pull-request "A.W.E.S.O.M-0 4000 prototype" \
+  bill-[awesomo4000]$ git pull-req "A.W.E.S.O.M-0 4000 prototype" \
                       -d "@sally, can you make sure Butters won't recognize it?"
     Pushing to 'awesomo4000' on 'origin'.
     Creating a pull request asking for 'awesomo4000' to be merged into 'master' on big_monies.
@@ -135,7 +135,7 @@ He creates his "Laaaaame" class and checks it in, with a pull request asking Sal
 
 Sally sees the email. After looking at it in the web interface, she wants to test it.
 
-  sally-[other_branch]$ git pull-request 3454
+  sally-[other_branch]$ git pull-req 3454
     Getting #pr_number
     Fetching the latest changes from the server
       new branch: awesomo4000
@@ -212,7 +212,7 @@ Profit!!
 
 == SEE ALSO ==
 
-*git-sync*(1), *git-to-master*(1), *git-new-fb*(1), *git-pull-request*(1)
+*git-sync*(1), *git-to-master*(1), *git-new-fb*(1), *git-pull-req*(1)
 
 
 == BUGS ==

data/docs/{git-pull-request.1.adoc → git-pull-req.1.adoc}

@@ -1,30 +1,29 @@
-GIT-PULL-REQUEST(1)
-===================
+= GIT-PULL-REQ(1) =
 :doctype: manpage
 
 
 NAME
 ----
-git-pull-request - Creates or gets a GitHub pull request.
+git-pull-req - Creates or gets a GitHub pull request.
 
 
 SYNOPSIS
 --------
-'git-pull-request' ['OPTIONS']
+'git-pull-req' ['OPTIONS']
 
-'git-pull-request' ['OPTIONS'] 'pull_request_title'
+'git-pull-req' ['OPTIONS'] 'pull_request_title'
 
-'git-pull-request' ['OPTIONS'] [ 'server/pull_request_number' | 'pull_request_number' ]
+'git-pull-req' ['OPTIONS'] [ 'server/pull_request_number' | 'pull_request_number' ]
 
 
 DESCRIPTION
 -----------
-'git-pull-request(1)' creates or gets a pull request on the GitHub
+'git-pull-req(1)' 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(1)' command is a nice, simplified alternative to using the
+The 'git-pull-req(1)' command is a nice, simplified alternative to using the
 web interface that takes advantage of the conventions used in the rest of the
 'git-process(1)' suite.
 
@@ -53,7 +52,7 @@ requirement to take advantage of same-repo pull request functionality.
 OPTIONS
 -------
 
-The effective default is "*git pull-request -r -i -f*".
+The effective default is "*git pull-req -r -i -f*".
 
 *-b <branch>, --base-branch <branch>*::
     The branch on the server that you want this "pulled" into. See the
@@ -131,7 +130,7 @@ EXAMPLE
 
 You've been developing your killer new feature or bug fix, and you want
 someone else to look at it (to do code-review or otherwise provide input).
-'git-pull-request(1)' synchronizes the current branch with
+'git-pull-req(1)' synchronizes the current branch with
 the server (effectively executing 'git-sync(1)') and creates the pull request
 against the integration branch.
 
@@ -140,7 +139,7 @@ CONTROL FILES
 -------------
 
 *gitprocess-sync-\***--**::
-    To help make the process simpler and more reliable, 'git-pull-request(1)' will put a file in the "'.git'" directory
+    To help make the process simpler and more reliable, 'git-pull-req(1)' will put a file in the "'.git'" directory
     that contains the SHA-1 of the last successful sync to the server. 'git-to-master(1)' will remove the file
     as part of its normal "housekeeping."
 

data/docs/git-sync.1.adoc

@@ -102,7 +102,7 @@ CONTROL FILES
 SEE ALSO
 --------
 
-*git-process*(1), *git-to-master*(1), *git-new-fb*(1), *git-pull-request*(1)
+*git-process*(1), *git-to-master*(1), *git-new-fb*(1), *git-pull-req*(1)
 
 
 BUGS

data/docs/git-to-master.1.adoc

@@ -37,7 +37,7 @@ It's assumed that you *never* do any work directly on the integration branch:
 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. (See
-'git-pull-request(1)'.)
+'git-pull-req(1)'.)
 
 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
@@ -72,7 +72,7 @@ and the integration branch on the server is "master", typing "*git to-master 493
 do roughly the following for you:
 
   $ git fetch -p
-  # looks up the information for pull-request 493
+  # 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
@@ -81,7 +81,7 @@ do roughly the following for you:
   $ 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(1)'
+If you would like the review the changes locally first, use 'git-pull-req(1)'
 instead.
 
 
@@ -144,7 +144,7 @@ CONTROL FILES
 GITHUB SUPPORT
 --------------
 
-To know which GitHub URL to use for pull-request support, the value of
+To know which GitHub URL to use for pull request support, the value of
 'gitProcess.remoteName' is resolved to the underlying server name/IP. (That includes
 "aliased" names in a 'ssh_config(5)' file.) If it's github.com, then the public
 GitHub.com API is used. Otherwise it's assumed that the server is GitHub Enterprise
@@ -154,7 +154,7 @@ and that set of URLs is used.
 SEE ALSO
 --------
 
-*git-process*(1), *git-sync*(1), *git-new-fb*(1), *git-pull-request*(1)
+*git-process*(1), *git-sync*(1), *git-new-fb*(1), *git-pull-req*(1)
 
 
 BUGS

data/git-process.gemspec

@@ -11,7 +11,7 @@ Gem::Specification.new do |gem|
   gem.add_dependency "git-sync", GitProc::Version::STRING
   gem.add_dependency "git-new-fb", GitProc::Version::STRING
   gem.add_dependency "git-to-master", GitProc::Version::STRING
-  gem.add_dependency "git-pull-request", GitProc::Version::STRING
+  gem.add_dependency "git-pull-req", GitProc::Version::STRING
 
   gem.files = %w(README.md LICENSE CHANGELOG.md)
   gem.files << 'man/git-process.1'

data/{git-pull-request.gemspec → git-pull-req.gemspec}

@@ -10,10 +10,10 @@ Gem::Specification.new do |gem|
 
   gem.add_dependency "git-process-lib", GitProc::Version::STRING
 
-  gem.files = %w(README.md LICENSE CHANGELOG.md bin/git-pull-request)
-  gem.files << 'man/git-pull-request.1'
-  gem.executables = ['git-pull-request']
-  gem.name = "git-pull-request"
+  gem.files = %w(README.md LICENSE CHANGELOG.md bin/git-pull-req)
+  gem.files << 'man/git-pull-req.1'
+  gem.executables = ['git-pull-req']
+  gem.name = "git-pull-req"
   gem.version = GitProc::Version::STRING
   gem.platform = Gem::Platform::RUBY
   gem.required_ruby_version = '>= 1.8.7'

data/lib/git-process/version.rb

@@ -14,7 +14,7 @@ module GitProc
   module Version
     MAJOR = 2
     MINOR = 0
-    PATCH = 0
+    PATCH = 1
     BUILD = nil
 
     STRING = [MAJOR, MINOR, PATCH, BUILD].compact.join('.')

data/local-build.rb

@@ -1,7 +1,7 @@
 #!/usr/bin/env ruby
 require File.expand_path('../lib/git-process/version', __FILE__)
 
-gems = %w(git-process-lib git-sync git-to-master git-new-fb git-pull-request git-process)
+gems = %w(git-process-lib git-sync git-to-master git-new-fb git-pull-req git-process)
 
 %x[rake manpage 2>&1]
 
@@ -20,5 +20,5 @@ end
 puts %x(gem install ./git-process-#{GitProc::Version::STRING}.gem -l -u)
 SystemExit.new($?) if $?.exitstatus
 
-puts %x(gem push ./git-process-#{GitProc::Version::STRING}.gem -l -u)
-SystemExit.new($?) if $?.exitstatus
+#puts %x(gem push ./git-process-#{GitProc::Version::STRING}.gem)
+#SystemExit.new($?) if $?.exitstatus

metadata

@@ -1,13 +1,13 @@
 --- !ruby/object:Gem::Specification 
 name: git-process-lib
 version: !ruby/object:Gem::Version 
-  hash: 15
+  hash: 13
   prerelease: 
   segments: 
   - 2
   - 0
-  - 0
-  version: 2.0.0
+  - 1
+  version: 2.0.1
 platform: ruby
 authors: 
 - Jim Moore
@@ -129,18 +129,18 @@ files:
 - README.md
 - Rakefile
 - bin/git-new-fb
-- bin/git-pull-request
+- bin/git-pull-req
 - bin/git-sync
 - bin/git-to-master
 - docs/git-new-fb.1.adoc
 - docs/git-process.1.adoc
-- docs/git-pull-request.1.adoc
+- docs/git-pull-req.1.adoc
 - docs/git-sync.1.adoc
 - docs/git-to-master.1.adoc
 - git-new-fb.gemspec
 - git-process-lib.gemspec
 - git-process.gemspec
-- git-pull-request.gemspec
+- git-pull-req.gemspec
 - git-sync.gemspec
 - git-to-master.gemspec
 - lib/git-process/abstract_error_builder.rb