git-process 1.0.11 → 1.1.0
Sign up to get free protection for your applications and to get access to all the features.
- data/CHANGELOG.md +37 -9
- data/Gemfile +2 -2
- data/Gemfile.lock +17 -17
- data/README.md +14 -7
- data/bin/git-new-fb +10 -2
- data/bin/git-pull-request +30 -6
- data/bin/git-sync +5 -2
- data/bin/git-to-master +62 -11
- data/git-process.gemspec +15 -15
- data/lib/git-process/abstract_error_builder.rb +0 -3
- data/lib/git-process/changed_file_helper.rb +30 -24
- data/lib/git-process/git_abstract_merge_error_builder.rb +31 -11
- data/lib/git-process/git_branch.rb +5 -0
- data/lib/git-process/git_config.rb +153 -0
- data/lib/git-process/git_lib.rb +212 -164
- data/lib/git-process/git_logger.rb +84 -0
- data/lib/git-process/git_merge_error.rb +3 -14
- data/lib/git-process/git_process.rb +44 -73
- data/lib/git-process/git_process_options.rb +6 -6
- data/lib/git-process/git_rebase_error.rb +4 -13
- data/lib/git-process/git_remote.rb +254 -0
- data/lib/git-process/github_configuration.rb +298 -0
- data/lib/git-process/github_pull_request.rb +65 -27
- data/lib/git-process/new_fb.rb +14 -4
- data/lib/git-process/parked_changes_error.rb +1 -1
- data/lib/git-process/pull_request.rb +100 -13
- data/lib/git-process/pull_request_error.rb +25 -0
- data/lib/git-process/rebase_to_master.rb +47 -27
- data/lib/git-process/sync.rb +48 -33
- data/lib/git-process/uncommitted_changes_error.rb +1 -1
- data/lib/git-process/version.rb +2 -2
- data/spec/GitRepoHelper.rb +48 -25
- data/spec/changed_file_helper_spec.rb +39 -58
- data/spec/git_abstract_merge_error_builder_spec.rb +42 -33
- data/spec/git_branch_spec.rb +30 -30
- data/spec/git_config_spec.rb +45 -0
- data/spec/git_lib_spec.rb +103 -122
- data/spec/git_logger_spec.rb +66 -0
- data/spec/git_process_spec.rb +81 -81
- data/spec/git_remote_spec.rb +188 -0
- data/spec/git_status_spec.rb +36 -36
- data/spec/github_configuration_spec.rb +152 -0
- data/spec/github_pull_request_spec.rb +39 -35
- data/spec/github_test_helper.rb +49 -0
- data/spec/new_fb_spec.rb +65 -24
- data/spec/pull_request_helper.rb +94 -0
- data/spec/pull_request_spec.rb +128 -0
- data/spec/rebase_to_master_spec.rb +241 -145
- data/spec/spec_helper.rb +20 -0
- data/spec/sync_spec.rb +115 -109
- metadata +34 -20
- data/lib/git-process/github_client.rb +0 -83
- data/lib/git-process/github_service.rb +0 -174
- data/spec/github_service_spec.rb +0 -211
data/CHANGELOG.md
CHANGED
@@ -1,12 +1,39 @@
|
|
1
|
-
# CHANGELOG - 1.0
|
2
|
-
|
3
|
-
### Since 1.0.10 ###
|
4
|
-
|
5
|
-
* Changed gemspec to use Octokit 1.22
|
1
|
+
# CHANGELOG - 1.1.0 #
|
6
2
|
|
7
3
|
### Since 1.0.8 ###
|
8
4
|
|
5
|
+
* Adds `git pull-request {repoName}/{branchNumber}` ([GH-92](https://github.com/jdigger/git-process/issues/92))
|
6
|
+
* If a number is given to "git-pull-request", or a number with a server preceding it (e.g., "origin/23"), then
|
7
|
+
this assumes that the number refers to an existing pull request identified by that number. In that case, the
|
8
|
+
branch associated with the HEAD of the pull request is checked out.
|
9
|
+
* Adds `git to-master {repoName}/{branchNumber}` ([GH-94](https://github.com/jdigger/git-process/issues/94))
|
10
|
+
* If a number is given to "git-to-master", or a number with a server preceding it (e.g., "origin/23"), then
|
11
|
+
this assumes that the number refers to an existing pull request identified by that number. In that case, the
|
12
|
+
branch associated with the HEAD of the pull request is checked out before doing the rest of the "to-master".
|
13
|
+
* `git new-fb` changes to work better with integration branch ([GH-99](https://github.com/jdigger/git-process/issues/99),
|
14
|
+
[GH-103](https://github.com/jdigger/git-process/issues/103) and [GH-105](https://github.com/jdigger/git-process/issues/105))
|
15
|
+
* Added pull-request URL to `git pull-request` output ([GH-104](https://github.com/jdigger/git-process/issues/104))
|
16
|
+
* Shows a cleaned up version of fetch's output. ([GH-85](https://github.com/jdigger/git-process/issues/85))
|
9
17
|
* Changed to use HTTPS instead of HTTP by default for GitHub API usage.
|
18
|
+
* Implementation details
|
19
|
+
* GitProc::PullRequest has #checkout_pull_request to checkout the HEAD branch of a pull request at any "remote"
|
20
|
+
that has been configured, setting the upstream to the pull request's BASE branch
|
21
|
+
* GitHubService module no longer uses module-level instance variables, which were causing problems with testing
|
22
|
+
* GitHub::PullRequest can now ask for a pull request by id
|
23
|
+
* Adds ability to set the upstream/tracking on a branch
|
24
|
+
* Upgrades to Octokit 1.24 and no longer overrides the Connection class
|
25
|
+
([GH-74](https://github.com/jdigger/git-process/issues/74))
|
26
|
+
* Adds module GitHubTestHelper
|
27
|
+
* Made GitLib and AbstractMergeErrorBuilder classes instead of modules
|
28
|
+
* Extracted GitCofig and GitRemote out of GitLib
|
29
|
+
* Changed to use GitLogger as a logging fascade
|
30
|
+
* GitProcess now takes a GitLib instead of a directory
|
31
|
+
* GitHubService refactoring; includes extracting GitHubService::Configuration and GitHub::CreatePullRequest.
|
32
|
+
* Supports RSpec default module for GitRepoHelper. Any RSpec context can declare :git_repo_helper as metadata to get
|
33
|
+
standard GitRepoHelper lifecycle support as part of [GH-97](https://github.com/jdigger/git-process/issues/97).
|
34
|
+
* Refactored GitHubService into GitHubService::Configuration
|
35
|
+
* Refatored GitHub::PullRequest
|
36
|
+
* Refatored GitLib#branch(..) and GitLib#command(..)
|
10
37
|
|
11
38
|
### Since 1.0.7 ###
|
12
39
|
|
@@ -26,13 +53,14 @@
|
|
26
53
|
|
27
54
|
### Since 1.0.4 ###
|
28
55
|
|
29
|
-
* Do not try to fetch/push when doing sync if there is not remote. (
|
30
|
-
* git-sync now merges in upstream changes. (
|
31
|
-
* Simplified Windows installation instructions. (
|
56
|
+
* Do not try to fetch/push when doing sync if there is not remote. ([GH-70](https://github.com/jdigger/git-process/issues/70))
|
57
|
+
* git-sync now merges in upstream changes. ([GH-79](https://github.com/jdigger/git-process/issues/79))
|
58
|
+
* Simplified Windows installation instructions. ([GH-76](https://github.com/jdigger/git-process/issues/76),
|
59
|
+
[GH-77](https://github.com/jdigger/git-process/issues/77))
|
32
60
|
|
33
61
|
### Since 1.0.3 ###
|
34
62
|
|
35
|
-
* Gets rid of
|
63
|
+
* Gets rid of infinite loop in Highline library. ([GH-72](https://github.com/jdigger/git-process/issues/72))
|
36
64
|
|
37
65
|
### Since 1.0.2 ###
|
38
66
|
|
data/Gemfile
CHANGED
@@ -1,7 +1,7 @@
|
|
1
1
|
source "http://rubygems.org"
|
2
2
|
|
3
3
|
group :default do
|
4
|
-
gem "octokit", "~> 1.
|
4
|
+
gem "octokit", "~> 1.24" # GitHub API
|
5
5
|
gem "json", "~> 1.7.3"
|
6
6
|
gem "trollop", "~> 1.16.2" # CLI options parser
|
7
7
|
gem "highline", "1.6.13" # user CLI interaction. There is a bug in 1.6.14
|
@@ -14,6 +14,6 @@ group :development do
|
|
14
14
|
end
|
15
15
|
|
16
16
|
group :test do
|
17
|
-
gem "rspec", "~> 2.
|
17
|
+
gem "rspec", "~> 2.12.0"
|
18
18
|
gem "webmock", "~> 1.8.7" # network mocking
|
19
19
|
end
|
data/Gemfile.lock
CHANGED
@@ -1,36 +1,36 @@
|
|
1
1
|
GEM
|
2
2
|
remote: http://rubygems.org/
|
3
3
|
specs:
|
4
|
-
addressable (2.3.
|
4
|
+
addressable (2.3.4)
|
5
5
|
crack (0.3.2)
|
6
6
|
diff-lcs (1.1.3)
|
7
|
-
faraday (0.8.
|
7
|
+
faraday (0.8.7)
|
8
8
|
multipart-post (~> 1.1)
|
9
9
|
faraday_middleware (0.9.0)
|
10
10
|
faraday (>= 0.7.4, < 0.9)
|
11
|
-
hashie (
|
11
|
+
hashie (2.0.3)
|
12
12
|
highline (1.6.13)
|
13
|
-
json (1.7.
|
14
|
-
multi_json (1.
|
15
|
-
multipart-post (1.
|
13
|
+
json (1.7.7)
|
14
|
+
multi_json (1.7.2)
|
15
|
+
multipart-post (1.2.0)
|
16
16
|
netrc (0.7.7)
|
17
|
-
octokit (1.
|
17
|
+
octokit (1.24.0)
|
18
18
|
addressable (~> 2.2)
|
19
19
|
faraday (~> 0.8)
|
20
20
|
faraday_middleware (~> 0.9)
|
21
|
-
hashie (~>
|
21
|
+
hashie (~> 2.0)
|
22
22
|
multi_json (~> 1.3)
|
23
23
|
netrc (~> 0.7.7)
|
24
24
|
rake (0.9.6)
|
25
25
|
redcarpet (2.1.1)
|
26
|
-
rspec (2.
|
27
|
-
rspec-core (~> 2.
|
28
|
-
rspec-expectations (~> 2.
|
29
|
-
rspec-mocks (~> 2.
|
30
|
-
rspec-core (2.
|
31
|
-
rspec-expectations (2.
|
26
|
+
rspec (2.12.0)
|
27
|
+
rspec-core (~> 2.12.0)
|
28
|
+
rspec-expectations (~> 2.12.0)
|
29
|
+
rspec-mocks (~> 2.12.0)
|
30
|
+
rspec-core (2.12.2)
|
31
|
+
rspec-expectations (2.12.1)
|
32
32
|
diff-lcs (~> 1.1.3)
|
33
|
-
rspec-mocks (2.
|
33
|
+
rspec-mocks (2.12.2)
|
34
34
|
trollop (1.16.2)
|
35
35
|
webmock (1.8.11)
|
36
36
|
addressable (>= 2.2.7)
|
@@ -43,10 +43,10 @@ PLATFORMS
|
|
43
43
|
DEPENDENCIES
|
44
44
|
highline (= 1.6.13)
|
45
45
|
json (~> 1.7.3)
|
46
|
-
octokit (~> 1.
|
46
|
+
octokit (~> 1.24)
|
47
47
|
rake (~> 0.9.2)
|
48
48
|
redcarpet (~> 2.1.1)
|
49
|
-
rspec (~> 2.
|
49
|
+
rspec (~> 2.12.0)
|
50
50
|
trollop (~> 1.16.2)
|
51
51
|
webmock (~> 1.8.7)
|
52
52
|
yard (~> 0.8.2.1)
|
data/README.md
CHANGED
@@ -1,8 +1,8 @@
|
|
1
|
-
[![Build Status](https://
|
1
|
+
[![Build Status](https://travis-ci.org/jdigger/git-process.png?branch=master)](https://travis-ci.org/jdigger/git-process)
|
2
2
|
|
3
3
|
# Purpose #
|
4
4
|
|
5
|
-
This provides an easy way to work with a sane git workflow process that encourages using highly-
|
5
|
+
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.
|
6
6
|
|
7
7
|
See the F.A.Q. for a much more complete explanation for the thoughts and assumptions that motivates this project.
|
8
8
|
|
@@ -25,7 +25,7 @@ Some older operating systems (such as OSX 10.6) are using an old version of Ruby
|
|
25
25
|
|
26
26
|
## Anticipated Use Cases ##
|
27
27
|
|
28
|
-
1. User creates new local branch for
|
28
|
+
1. User creates new local branch for focused work.
|
29
29
|
1. User pushes local branch to remote (as feature branch) by merging/rebasing with the integration branch, then pushing to the branch to remote.
|
30
30
|
1. User closes local branch by rebasing integration branch first, then pushing local to integration.
|
31
31
|
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
|
|
35
35
|
* `git new-fb` - Create a new feature branch based on the integration branch.
|
36
36
|
* `git sync` - Gets the latest changes that have happened on the integration branch, then pushes your changes to a "private" branch on the server.
|
37
37
|
* `git pull-request` - Creates a Pull Request for the current branch.
|
38
|
-
* `git to-master` - Rebase against the integration branch, then pushes to it.
|
38
|
+
* `git to-master` - Rebase against the integration branch, then pushes to it. Knows how to deal "intelligently" with pull-requests.
|
39
39
|
|
40
40
|
**All commands are well documented within themselves: Use the "-h" switch to see the full documentation.** (e.g., "`git sync -h`")
|
41
41
|
|
@@ -52,10 +52,16 @@ _The following assumes that the integration branch is "origin/master"._
|
|
52
52
|
as save your work on the server, do "`git sync`".
|
53
53
|
* That will merge in the changes that have occurred in "`origin/master`" and then push the
|
54
54
|
result to the "`feature_branch`" branch to the server.
|
55
|
-
3. When you feel your work is ready for others to look at, do
|
56
|
-
|
57
|
-
|
55
|
+
3. When you feel your work is ready for others to look at, do "`git pull-request`" to ask someone to review your changes.
|
56
|
+
* 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.
|
57
|
+
* Any changes you make via "`git sync`" are automatically reflected in the pull request.
|
58
|
+
4. As a reviewer, to see a pull-request, do "`git pull-request ##`" (where "##" is the pull request number) to check
|
59
|
+
out the branch associated with the pull request in your repository.
|
60
|
+
5. If you get the thumbs up from the code-review, use "`git to-master`".
|
58
61
|
* This will merge and push your changes into "`origin/master`", closing the pull request.
|
62
|
+
* If reviewing the pull request via the web interface was sufficient, or there is otherwise not a reason
|
63
|
+
to explicitly checkout the branch first, you can use "`git to-master`" with the pull request number to
|
64
|
+
combine both of these steps.
|
59
65
|
5. If you still need to make changes, do so and use "`git sync`" to keep your branch on the
|
60
66
|
server for that feature updated with your work until all issues have been resolved.
|
61
67
|
|
@@ -119,6 +125,7 @@ $ git to-master # 6
|
|
119
125
|
* 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`")
|
120
126
|
* This tries to respond "intelligently" to the use of 'rerere'.
|
121
127
|
* 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.
|
128
|
+
* `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.)
|
122
129
|
|
123
130
|
|
124
131
|
# F.A.Q. #
|
data/bin/git-new-fb
CHANGED
@@ -1,10 +1,17 @@
|
|
1
1
|
#!/usr/bin/env ruby
|
2
2
|
|
3
|
+
#require "rubygems"
|
4
|
+
#require "bundler/setup"
|
5
|
+
#$LOAD_PATH.unshift File.join(File.dirname(__FILE__), '../lib')
|
6
|
+
|
3
7
|
require 'git-process/git_process_options'
|
4
8
|
require 'git-process/new_fb'
|
9
|
+
require 'git-process/git_lib'
|
10
|
+
include GitProc
|
11
|
+
|
5
12
|
|
6
13
|
class NewFeatureBranchOptions
|
7
|
-
include
|
14
|
+
include GitProcessOptions
|
8
15
|
|
9
16
|
def summary
|
10
17
|
"Create a new feature branch based on the integration branch."
|
@@ -47,4 +54,5 @@ DESC
|
|
47
54
|
|
48
55
|
end
|
49
56
|
|
50
|
-
|
57
|
+
opts = NewFeatureBranchOptions.new.parse_cli(File.basename(__FILE__), ARGV)
|
58
|
+
NewFeatureBranch.new(GitLib.new('.', opts), opts).run
|
data/bin/git-pull-request
CHANGED
@@ -1,14 +1,20 @@
|
|
1
1
|
#!/usr/bin/env ruby
|
2
2
|
|
3
|
+
#require "rubygems"
|
4
|
+
#require "bundler/setup"
|
5
|
+
#$LOAD_PATH.unshift File.join(File.dirname(__FILE__), '../lib')
|
6
|
+
|
7
|
+
require 'git-process/git_lib'
|
3
8
|
require 'git-process/pull_request'
|
4
9
|
require 'git-process/git_process_options'
|
10
|
+
include GitProc
|
5
11
|
|
6
12
|
class PullRequestOptions
|
7
|
-
include
|
13
|
+
include GitProcessOptions
|
8
14
|
|
9
15
|
|
10
16
|
def summary
|
11
|
-
"Creates a Pull Request
|
17
|
+
"Creates or gets a Pull Request."
|
12
18
|
end
|
13
19
|
|
14
20
|
|
@@ -16,13 +22,21 @@ class PullRequestOptions
|
|
16
22
|
<<DESC
|
17
23
|
DESCRIPTION
|
18
24
|
|
19
|
-
This creates a Pull Request on the GitHub server associated with the current \
|
25
|
+
This creates or gets a Pull Request on the GitHub server associated with the current \
|
20
26
|
branch. For the reasons why Pull Requests are useful for the development process, \
|
21
27
|
see https://help.github.com/articles/using-pull-requests
|
22
28
|
|
23
29
|
The "git pull-request" command is a nice, simplified alternative to using the \
|
24
30
|
web interface.
|
25
31
|
|
32
|
+
If no name or number is provided, it is assumed that you want to create a new \
|
33
|
+
pull request with the same name as the current branch.
|
34
|
+
|
35
|
+
If a number is given, or a number with a server preceding it (e.g., "origin/23"), \
|
36
|
+
then this assumes that the number refers to an existing pull request identified \
|
37
|
+
by that number. In that case, the branch associated with the HEAD of the pull \
|
38
|
+
request is checked out.
|
39
|
+
|
26
40
|
EXAMPLE
|
27
41
|
|
28
42
|
You've been developing your killer new feature or bug fix, and you want \
|
@@ -53,7 +67,7 @@ DESC
|
|
53
67
|
|
54
68
|
|
55
69
|
def usage(filename)
|
56
|
-
"Usage: #{filename} [ options ] pull_request_title"
|
70
|
+
"Usage: #{filename} [ options ] [pull_request_title | server/pull_request_number | pull_request_number]"
|
57
71
|
end
|
58
72
|
|
59
73
|
|
@@ -75,9 +89,19 @@ DESC
|
|
75
89
|
|
76
90
|
|
77
91
|
def post_parse(opts, argv)
|
78
|
-
|
92
|
+
arg = argv.shift
|
93
|
+
if /^\d+$/ =~ arg
|
94
|
+
opts[:prNumber] = arg
|
95
|
+
elsif /^(.*)\/(\d+)$/ =~ arg
|
96
|
+
m = /^(.*)\/(\d+)$/.match(arg)
|
97
|
+
opts[:server] = m[1]
|
98
|
+
opts[:prNumber] = m[2]
|
99
|
+
else
|
100
|
+
opts[:title] = arg
|
101
|
+
end
|
79
102
|
end
|
80
103
|
|
81
104
|
end
|
82
105
|
|
83
|
-
|
106
|
+
opts = PullRequestOptions.new.parse_cli(File.basename(__FILE__), ARGV)
|
107
|
+
GitProc::PullRequest.new(GitLib.new('.', opts), opts).run
|
data/bin/git-sync
CHANGED
@@ -6,10 +6,11 @@
|
|
6
6
|
|
7
7
|
require 'git-process/git_process_options'
|
8
8
|
require 'git-process/sync'
|
9
|
+
require 'git-process/git_lib'
|
9
10
|
|
10
11
|
|
11
12
|
class SyncOptions
|
12
|
-
include
|
13
|
+
include GitProcessOptions
|
13
14
|
|
14
15
|
|
15
16
|
def summary
|
@@ -60,6 +61,7 @@ DESC
|
|
60
61
|
end
|
61
62
|
|
62
63
|
|
64
|
+
#noinspection RubyUnusedLocalVariable
|
63
65
|
def post_parse(opts, argv)
|
64
66
|
opts[:force] = true if opts[:rebase]
|
65
67
|
opts[:merge] = !opts[:rebase]
|
@@ -67,4 +69,5 @@ DESC
|
|
67
69
|
|
68
70
|
end
|
69
71
|
|
70
|
-
|
72
|
+
opts = SyncOptions.new.parse_cli(File.basename(__FILE__), ARGV)
|
73
|
+
GitProc::Sync.new(GitLib.new('.', opts), opts).run
|
data/bin/git-to-master
CHANGED
@@ -1,7 +1,13 @@
|
|
1
1
|
#!/usr/bin/env ruby
|
2
2
|
|
3
|
+
require "rubygems"
|
4
|
+
require "bundler/setup"
|
5
|
+
$LOAD_PATH.unshift File.join(File.dirname(__FILE__), '../lib')
|
6
|
+
|
3
7
|
require 'git-process/git_process_options'
|
4
8
|
require 'git-process/rebase_to_master'
|
9
|
+
require 'git-process/git_lib'
|
10
|
+
|
5
11
|
|
6
12
|
class ToMasterOptions
|
7
13
|
include GitProc::GitProcessOptions
|
@@ -39,28 +45,53 @@ everything is done on a feature branch. In addition to being a much \
|
|
39
45
|
safer and more flexible way of working in general, it is also a \
|
40
46
|
requirement to take advantage of Pull Request functionality.
|
41
47
|
|
42
|
-
By default the first server name reported by 'git remote' is used as the
|
43
|
-
Since most projects only have a single remote (i.e.,
|
44
|
-
But if you have multiple remotes and
|
45
|
-
'gitProcess.remoteName' configuration option.
|
48
|
+
By default the first server name reported by 'git remote' is used as the \
|
49
|
+
server/remote name. Since most projects only have a single remote (i.e., \
|
50
|
+
"origin") this works most of the time. But if you have multiple remotes and \
|
51
|
+
want to explicitly set it, use the 'gitProcess.remoteName' configuration option.
|
52
|
+
|
53
|
+
If a number is given, or a number with a server preceding it (e.g., \
|
54
|
+
"origin/23"), then this assumes that the number refers to an existing pull \
|
55
|
+
request identified by that number. In that case, the branch associated with \
|
56
|
+
the HEAD of the pull request is checked out before doing the rest of the \
|
57
|
+
"to-master".
|
46
58
|
|
47
|
-
EXAMPLE
|
59
|
+
EXAMPLE WITHOUT PULL REQUEST
|
48
60
|
|
49
|
-
Assuming that the current branch is called "interesting_changes" and the
|
50
|
-
branch on the server is "master", typing "git to-master" will do
|
51
|
-
for you:
|
61
|
+
Assuming that the current branch is called "interesting_changes" and the \
|
62
|
+
integration branch on the server is "master", typing "git to-master" will do \
|
63
|
+
roughly the following for you:
|
52
64
|
$ git fetch -p
|
53
65
|
$ git rebase origin/master
|
54
66
|
$ git push origin interesting_changes:master
|
55
|
-
# close pull request
|
67
|
+
# close pull request if one exists
|
56
68
|
$ git checkout -b _parking_ origin/master
|
57
69
|
$ git branch -d interesting_changes
|
58
|
-
$ git push origin
|
70
|
+
$ git push origin --delete interesting_changes
|
59
71
|
|
60
72
|
If you use the --interactive option, then it does an interactive rebase before the first "push".
|
61
73
|
|
62
74
|
If you use the --keep option, then the process stops after the first "push".
|
63
75
|
|
76
|
+
|
77
|
+
EXAMPLE WITH PULL REQUEST
|
78
|
+
|
79
|
+
Assuming that the pull request number is 493, its branch name is "interesting_changes" \
|
80
|
+
and the integration branch on the server is "master", typing "git to-master 493" will \
|
81
|
+
do roughly the following for you:
|
82
|
+
$ git fetch -p
|
83
|
+
# looks up the information for pull-request 493
|
84
|
+
$ git checkout -b interesting_changes origin/interesting_changes
|
85
|
+
$ git rebase origin/master
|
86
|
+
$ git push origin interesting_changes:master
|
87
|
+
# close pull request
|
88
|
+
$ git checkout -b _parking_ origin/master
|
89
|
+
$ git branch -d interesting_changes
|
90
|
+
$ git push origin --delete interesting_changes
|
91
|
+
|
92
|
+
If you would like the review the changes locally first, use "git pull-request 493"
|
93
|
+
instead.
|
94
|
+
|
64
95
|
NOTES
|
65
96
|
|
66
97
|
* If you want to use a different integration branch other than "master",
|
@@ -70,6 +101,10 @@ NOTES
|
|
70
101
|
DESC
|
71
102
|
end
|
72
103
|
|
104
|
+
def usage(filename)
|
105
|
+
"Usage: #{filename} [ options ] [server/pull_request_number | pull_request_number]"
|
106
|
+
end
|
107
|
+
|
73
108
|
|
74
109
|
def extend_opts(parser)
|
75
110
|
parser.opt :keep, "Don't do any \"cleanup.\" It keeps the current local "+
|
@@ -78,6 +113,22 @@ DESC
|
|
78
113
|
parser.opt :interactive, "Do an interactive rebase before pushing to the server.", :short => :i, :default => false
|
79
114
|
end
|
80
115
|
|
116
|
+
|
117
|
+
def post_parse(opts, argv)
|
118
|
+
arg = argv.shift
|
119
|
+
if /^\d+$/ =~ arg
|
120
|
+
opts[:prNumber] = arg
|
121
|
+
elsif /^(.*)\/(\d+)$/ =~ arg
|
122
|
+
m = /^(.*)\/(\d+)$/.match(arg)
|
123
|
+
opts[:server] = m[1]
|
124
|
+
opts[:prNumber] = m[2]
|
125
|
+
else
|
126
|
+
# "normal" to-master
|
127
|
+
end
|
128
|
+
end
|
129
|
+
|
81
130
|
end
|
82
131
|
|
83
|
-
|
132
|
+
opts = ToMasterOptions.new.parse_cli(File.basename(__FILE__), ARGV)
|
133
|
+
#GitProc::RebaseToMaster.new(GitLib.new('.', opts), opts).run
|
134
|
+
puts opts.inspect
|
data/git-process.gemspec
CHANGED
@@ -1,24 +1,24 @@
|
|
1
1
|
require File.expand_path('../lib/git-process/version', __FILE__)
|
2
2
|
|
3
|
-
|
4
|
-
gem.authors
|
5
|
-
gem.email
|
6
|
-
gem.description
|
7
|
-
gem.summary
|
8
|
-
gem.homepage
|
9
|
-
gem.license
|
3
|
+
Gem::Specification.new do |gem|
|
4
|
+
gem.authors = ["Jim Moore"]
|
5
|
+
gem.email = %w(moore.jim@gmail.com)
|
6
|
+
gem.description = %q{A set of scripts to make working with git easier and more consistent}
|
7
|
+
gem.summary = %q{A set of scripts for a good git process}
|
8
|
+
gem.homepage = "http://jdigger.github.com/git-process/"
|
9
|
+
gem.license = 'ASL2'
|
10
10
|
|
11
|
-
gem.add_dependency "octokit", "~> 1.
|
11
|
+
gem.add_dependency "octokit", "~> 1.24" # GitHub API
|
12
12
|
gem.add_dependency "json", "~> 1.7.3"
|
13
13
|
gem.add_dependency "trollop", "~> 1.16.2" # CLI options parser
|
14
14
|
gem.add_dependency "highline", "1.6.13" # user CLI interaction. There is a bug in 1.6.14
|
15
15
|
|
16
|
-
gem.files
|
17
|
-
gem.executables
|
18
|
-
gem.test_files
|
19
|
-
gem.name
|
20
|
-
gem.require_paths =
|
21
|
-
gem.version
|
22
|
-
gem.platform
|
16
|
+
gem.files = `git ls-files`.split($\).delete_if { |f| f =~ /^\./ }
|
17
|
+
gem.executables = gem.files.grep(%r{^bin/}).map { |f| File.basename(f) }
|
18
|
+
gem.test_files = gem.files.grep(%r{^(test|spec|features)/})
|
19
|
+
gem.name = "git-process"
|
20
|
+
gem.require_paths = %w(lib)
|
21
|
+
gem.version = GitProc::Version::STRING
|
22
|
+
gem.platform = Gem::Platform::RUBY
|
23
23
|
gem.required_ruby_version = '>= 1.8.7'
|
24
24
|
end
|