git-process-lib 2.0.0 → 2.0.1
Sign up to get free protection for your applications and to get access to all the features.
- data/CHANGELOG.md +4 -0
- data/README.md +6 -25
- data/bin/{git-pull-request → git-pull-req} +0 -0
- data/docs/git-new-fb.1.adoc +1 -1
- data/docs/git-process.1.adoc +3 -3
- data/docs/{git-pull-request.1.adoc → git-pull-req.1.adoc} +10 -11
- data/docs/git-sync.1.adoc +1 -1
- data/docs/git-to-master.1.adoc +5 -5
- data/git-process.gemspec +1 -1
- data/{git-pull-request.gemspec → git-pull-req.gemspec} +4 -4
- data/lib/git-process/version.rb +1 -1
- data/local-build.rb +3 -3
- metadata +6 -6
data/CHANGELOG.md
CHANGED
data/README.md
CHANGED
@@ -50,7 +50,7 @@ To get full `git help` and manpage support, do:
|
|
50
50
|
|
51
51
|
* `git new-fb` - Create a new feature branch based on the integration branch.
|
52
52
|
* `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.
|
53
|
-
* `git pull-
|
53
|
+
* `git pull-req` - Create or get a Pull Request for the current branch.
|
54
54
|
* `git to-master` - Rebase against the integration branch, then pushes to it. Knows how to deal "intelligently" with pull-requests.
|
55
55
|
|
56
56
|
**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:
|
|
73
73
|
* "`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.
|
74
74
|
* "`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.
|
75
75
|
* The process that you use should be essentially the same, regardless of whether you are working alone, or on a large distributed team.
|
76
|
-
* The exception here is "`git pull-
|
76
|
+
* The exception here is "`git pull-req`" since you typically do not use pull requests when working solo or when pair-programming.
|
77
77
|
|
78
78
|
|
79
79
|
# Notes #
|
80
80
|
|
81
81
|
* 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`").
|
82
82
|
* 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.
|
83
|
-
* The first time you use a GitHub feature (e.g., "`git pull-
|
83
|
+
* 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`".
|
84
84
|
* 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`")
|
85
85
|
* 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.
|
86
|
-
* `git pull-
|
86
|
+
* `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.)
|
87
87
|
|
88
88
|
|
89
89
|
# Workflow Examples #
|
@@ -178,7 +178,7 @@ He creates his "Laaaaame" class and checks it in, with a pull request asking Sal
|
|
178
178
|
|
179
179
|
```
|
180
180
|
bill-[awesomo4000]$ git commit
|
181
|
-
bill-[awesomo4000]$ git pull-
|
181
|
+
bill-[awesomo4000]$ git pull-req "A.W.E.S.O.M-0 4000 prototype" \
|
182
182
|
-d "@sally, can you make sure Butters won't recognize it?"
|
183
183
|
Pushing to 'awesomo4000' on 'origin'.
|
184
184
|
Creating a pull request asking for 'awesomo4000' to be merged into 'master' on big_monies.
|
@@ -189,7 +189,7 @@ bill-[awesomo4000]$
|
|
189
189
|
Sally sees the email. After looking at it in the web interface, she wants to test it.
|
190
190
|
|
191
191
|
```
|
192
|
-
sally-[other_branch]$ git pull-
|
192
|
+
sally-[other_branch]$ git pull-req 3454
|
193
193
|
Getting #pr_number
|
194
194
|
Fetching the latest changes from the server
|
195
195
|
new branch: awesomo4000
|
@@ -308,25 +308,6 @@ One significant advantage of using automation like this is that it lets you have
|
|
308
308
|
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.
|
309
309
|
|
310
310
|
|
311
|
-
# Contributing #
|
312
|
-
|
313
|
-
## Coding Setup ##
|
314
|
-
|
315
|
-
1. Fork it
|
316
|
-
2. Create your feature branch (`git checkout -b my-new-feature origin/master`)
|
317
|
-
3. Commit your changes (`git commit`)
|
318
|
-
4. Push to the branch (`git push origin my-new-feature`)
|
319
|
-
5. Create new Pull Request
|
320
|
-
|
321
|
-
or, if using these scripts:
|
322
|
-
|
323
|
-
1. Fork it
|
324
|
-
2. `git new-fb my-new-feature
|
325
|
-
3. `git commit`
|
326
|
-
4. `git sync`
|
327
|
-
5. `git pull-request`
|
328
|
-
|
329
|
-
|
330
311
|
## License ##
|
331
312
|
|
332
313
|
Licensed under the Apache License, Version 2.0 (the "License");
|
File without changes
|
data/docs/git-new-fb.1.adoc
CHANGED
data/docs/git-process.1.adoc
CHANGED
@@ -126,7 +126,7 @@ Meanwhile Bill has been working on his great idea:
|
|
126
126
|
He creates his "Laaaaame" class and checks it in, with a pull request asking Sally to do a code review.
|
127
127
|
|
128
128
|
bill-[awesomo4000]$ git commit
|
129
|
-
bill-[awesomo4000]$ git pull-
|
129
|
+
bill-[awesomo4000]$ git pull-req "A.W.E.S.O.M-0 4000 prototype" \
|
130
130
|
-d "@sally, can you make sure Butters won't recognize it?"
|
131
131
|
Pushing to 'awesomo4000' on 'origin'.
|
132
132
|
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
|
|
135
135
|
|
136
136
|
Sally sees the email. After looking at it in the web interface, she wants to test it.
|
137
137
|
|
138
|
-
sally-[other_branch]$ git pull-
|
138
|
+
sally-[other_branch]$ git pull-req 3454
|
139
139
|
Getting #pr_number
|
140
140
|
Fetching the latest changes from the server
|
141
141
|
new branch: awesomo4000
|
@@ -212,7 +212,7 @@ Profit!!
|
|
212
212
|
|
213
213
|
== SEE ALSO ==
|
214
214
|
|
215
|
-
*git-sync*(1), *git-to-master*(1), *git-new-fb*(1), *git-pull-
|
215
|
+
*git-sync*(1), *git-to-master*(1), *git-new-fb*(1), *git-pull-req*(1)
|
216
216
|
|
217
217
|
|
218
218
|
== BUGS ==
|
@@ -1,30 +1,29 @@
|
|
1
|
-
GIT-PULL-
|
2
|
-
===================
|
1
|
+
= GIT-PULL-REQ(1) =
|
3
2
|
:doctype: manpage
|
4
3
|
|
5
4
|
|
6
5
|
NAME
|
7
6
|
----
|
8
|
-
git-pull-
|
7
|
+
git-pull-req - Creates or gets a GitHub pull request.
|
9
8
|
|
10
9
|
|
11
10
|
SYNOPSIS
|
12
11
|
--------
|
13
|
-
'git-pull-
|
12
|
+
'git-pull-req' ['OPTIONS']
|
14
13
|
|
15
|
-
'git-pull-
|
14
|
+
'git-pull-req' ['OPTIONS'] 'pull_request_title'
|
16
15
|
|
17
|
-
'git-pull-
|
16
|
+
'git-pull-req' ['OPTIONS'] [ 'server/pull_request_number' | 'pull_request_number' ]
|
18
17
|
|
19
18
|
|
20
19
|
DESCRIPTION
|
21
20
|
-----------
|
22
|
-
'git-pull-
|
21
|
+
'git-pull-req(1)' creates or gets a pull request on the GitHub
|
23
22
|
server associated with the current branch. For the reasons why pull
|
24
23
|
requests are useful for the development process,
|
25
24
|
see <https://help.github.com/articles/using-pull-requests>
|
26
25
|
|
27
|
-
The 'git-pull-
|
26
|
+
The 'git-pull-req(1)' command is a nice, simplified alternative to using the
|
28
27
|
web interface that takes advantage of the conventions used in the rest of the
|
29
28
|
'git-process(1)' suite.
|
30
29
|
|
@@ -53,7 +52,7 @@ requirement to take advantage of same-repo pull request functionality.
|
|
53
52
|
OPTIONS
|
54
53
|
-------
|
55
54
|
|
56
|
-
The effective default is "*git pull-
|
55
|
+
The effective default is "*git pull-req -r -i -f*".
|
57
56
|
|
58
57
|
*-b <branch>, --base-branch <branch>*::
|
59
58
|
The branch on the server that you want this "pulled" into. See the
|
@@ -131,7 +130,7 @@ EXAMPLE
|
|
131
130
|
|
132
131
|
You've been developing your killer new feature or bug fix, and you want
|
133
132
|
someone else to look at it (to do code-review or otherwise provide input).
|
134
|
-
'git-pull-
|
133
|
+
'git-pull-req(1)' synchronizes the current branch with
|
135
134
|
the server (effectively executing 'git-sync(1)') and creates the pull request
|
136
135
|
against the integration branch.
|
137
136
|
|
@@ -140,7 +139,7 @@ CONTROL FILES
|
|
140
139
|
-------------
|
141
140
|
|
142
141
|
*gitprocess-sync-\***--**::
|
143
|
-
To help make the process simpler and more reliable, 'git-pull-
|
142
|
+
To help make the process simpler and more reliable, 'git-pull-req(1)' will put a file in the "'.git'" directory
|
144
143
|
that contains the SHA-1 of the last successful sync to the server. 'git-to-master(1)' will remove the file
|
145
144
|
as part of its normal "housekeeping."
|
146
145
|
|
data/docs/git-sync.1.adoc
CHANGED
data/docs/git-to-master.1.adoc
CHANGED
@@ -37,7 +37,7 @@ It's assumed that you *never* do any work directly on the integration branch:
|
|
37
37
|
everything is done on a feature branch. In addition to being a much
|
38
38
|
safer and more flexible way of working in general, it is also a
|
39
39
|
requirement to take advantage of pull request functionality. (See
|
40
|
-
'git-pull-
|
40
|
+
'git-pull-req(1)'.)
|
41
41
|
|
42
42
|
If a number is given, or a number with a server preceding it (e.g.,
|
43
43
|
"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
|
|
72
72
|
do roughly the following for you:
|
73
73
|
|
74
74
|
$ git fetch -p
|
75
|
-
# looks up the information for pull
|
75
|
+
# looks up the information for pull request 493
|
76
76
|
$ git checkout -b interesting_changes origin/interesting_changes
|
77
77
|
$ git rebase origin/master
|
78
78
|
$ git push origin interesting_changes:master
|
@@ -81,7 +81,7 @@ do roughly the following for you:
|
|
81
81
|
$ git branch -d interesting_changes
|
82
82
|
$ git push origin --delete interesting_changes
|
83
83
|
|
84
|
-
If you would like the review the changes locally first, use 'git-pull-
|
84
|
+
If you would like the review the changes locally first, use 'git-pull-req(1)'
|
85
85
|
instead.
|
86
86
|
|
87
87
|
|
@@ -144,7 +144,7 @@ CONTROL FILES
|
|
144
144
|
GITHUB SUPPORT
|
145
145
|
--------------
|
146
146
|
|
147
|
-
To know which GitHub URL to use for pull
|
147
|
+
To know which GitHub URL to use for pull request support, the value of
|
148
148
|
'gitProcess.remoteName' is resolved to the underlying server name/IP. (That includes
|
149
149
|
"aliased" names in a 'ssh_config(5)' file.) If it's github.com, then the public
|
150
150
|
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.
|
|
154
154
|
SEE ALSO
|
155
155
|
--------
|
156
156
|
|
157
|
-
*git-process*(1), *git-sync*(1), *git-new-fb*(1), *git-pull-
|
157
|
+
*git-process*(1), *git-sync*(1), *git-new-fb*(1), *git-pull-req*(1)
|
158
158
|
|
159
159
|
|
160
160
|
BUGS
|
data/git-process.gemspec
CHANGED
@@ -11,7 +11,7 @@ Gem::Specification.new do |gem|
|
|
11
11
|
gem.add_dependency "git-sync", GitProc::Version::STRING
|
12
12
|
gem.add_dependency "git-new-fb", GitProc::Version::STRING
|
13
13
|
gem.add_dependency "git-to-master", GitProc::Version::STRING
|
14
|
-
gem.add_dependency "git-pull-
|
14
|
+
gem.add_dependency "git-pull-req", GitProc::Version::STRING
|
15
15
|
|
16
16
|
gem.files = %w(README.md LICENSE CHANGELOG.md)
|
17
17
|
gem.files << 'man/git-process.1'
|
@@ -10,10 +10,10 @@ Gem::Specification.new do |gem|
|
|
10
10
|
|
11
11
|
gem.add_dependency "git-process-lib", GitProc::Version::STRING
|
12
12
|
|
13
|
-
gem.files = %w(README.md LICENSE CHANGELOG.md bin/git-pull-
|
14
|
-
gem.files << 'man/git-pull-
|
15
|
-
gem.executables = ['git-pull-
|
16
|
-
gem.name = "git-pull-
|
13
|
+
gem.files = %w(README.md LICENSE CHANGELOG.md bin/git-pull-req)
|
14
|
+
gem.files << 'man/git-pull-req.1'
|
15
|
+
gem.executables = ['git-pull-req']
|
16
|
+
gem.name = "git-pull-req"
|
17
17
|
gem.version = GitProc::Version::STRING
|
18
18
|
gem.platform = Gem::Platform::RUBY
|
19
19
|
gem.required_ruby_version = '>= 1.8.7'
|
data/lib/git-process/version.rb
CHANGED
data/local-build.rb
CHANGED
@@ -1,7 +1,7 @@
|
|
1
1
|
#!/usr/bin/env ruby
|
2
2
|
require File.expand_path('../lib/git-process/version', __FILE__)
|
3
3
|
|
4
|
-
gems = %w(git-process-lib git-sync git-to-master git-new-fb git-pull-
|
4
|
+
gems = %w(git-process-lib git-sync git-to-master git-new-fb git-pull-req git-process)
|
5
5
|
|
6
6
|
%x[rake manpage 2>&1]
|
7
7
|
|
@@ -20,5 +20,5 @@ end
|
|
20
20
|
puts %x(gem install ./git-process-#{GitProc::Version::STRING}.gem -l -u)
|
21
21
|
SystemExit.new($?) if $?.exitstatus
|
22
22
|
|
23
|
-
puts %x(gem push ./git-process-#{GitProc::Version::STRING}.gem
|
24
|
-
SystemExit.new($?) if $?.exitstatus
|
23
|
+
#puts %x(gem push ./git-process-#{GitProc::Version::STRING}.gem)
|
24
|
+
#SystemExit.new($?) if $?.exitstatus
|
metadata
CHANGED
@@ -1,13 +1,13 @@
|
|
1
1
|
--- !ruby/object:Gem::Specification
|
2
2
|
name: git-process-lib
|
3
3
|
version: !ruby/object:Gem::Version
|
4
|
-
hash:
|
4
|
+
hash: 13
|
5
5
|
prerelease:
|
6
6
|
segments:
|
7
7
|
- 2
|
8
8
|
- 0
|
9
|
-
-
|
10
|
-
version: 2.0.
|
9
|
+
- 1
|
10
|
+
version: 2.0.1
|
11
11
|
platform: ruby
|
12
12
|
authors:
|
13
13
|
- Jim Moore
|
@@ -129,18 +129,18 @@ files:
|
|
129
129
|
- README.md
|
130
130
|
- Rakefile
|
131
131
|
- bin/git-new-fb
|
132
|
-
- bin/git-pull-
|
132
|
+
- bin/git-pull-req
|
133
133
|
- bin/git-sync
|
134
134
|
- bin/git-to-master
|
135
135
|
- docs/git-new-fb.1.adoc
|
136
136
|
- docs/git-process.1.adoc
|
137
|
-
- docs/git-pull-
|
137
|
+
- docs/git-pull-req.1.adoc
|
138
138
|
- docs/git-sync.1.adoc
|
139
139
|
- docs/git-to-master.1.adoc
|
140
140
|
- git-new-fb.gemspec
|
141
141
|
- git-process-lib.gemspec
|
142
142
|
- git-process.gemspec
|
143
|
-
- git-pull-
|
143
|
+
- git-pull-req.gemspec
|
144
144
|
- git-sync.gemspec
|
145
145
|
- git-to-master.gemspec
|
146
146
|
- lib/git-process/abstract_error_builder.rb
|