This is an automated email from the ASF dual-hosted git repository.
rabbah pushed a commit to branch master
in repository https://gitbox.apache.org/repos/asf/incubator-openwhisk.wiki.git
The following commit(s) were added to refs/heads/master by this push:
new 6281391 Revert
fd970e4dceb8614c9b23811286336fdc261be6ce...f27cbd459358584f18480fac65a546ed90e276b8
on Contributing: Git guidelines
6281391 is described below
commit 62813915671c7351507baed4c3077c013fb055ed
Author: rodric rabbah <rod...@gmail.com>
AuthorDate: Fri Mar 2 13:31:22 2018 -0500
Revert
fd970e4dceb8614c9b23811286336fdc261be6ce...f27cbd459358584f18480fac65a546ed90e276b8
on Contributing: Git guidelines
---
Contributing:-Git-guidelines.md | 30 ++++++++++++++++++++++++++++++
1 file changed, 30 insertions(+)
diff --git a/Contributing:-Git-guidelines.md b/Contributing:-Git-guidelines.md
index 5cc0264..3d54ad7 100644
--- a/Contributing:-Git-guidelines.md
+++ b/Contributing:-Git-guidelines.md
@@ -72,12 +72,16 @@ The instructions assume that the merger has set up a git
remote with the name `u
2. Checkout your fork:
+ ```
git clone g...@github.com:yourname/incubator-openwhisk
+ ```
3. Add upstream remote:
+ ```
git remote add upstream g...@github.com:apache/incubator-openwhisk
git fetch --all
+ ```
After this setup, your local `master`, should point to the same commit as
`origin/master` and `upstream/master`. You can confirm that by running, e.g.,
`git log -1 --decorate` (FWIW, for log inspection, I personally recommend using
[`tig`](https://github.com/jonas/tig)).
@@ -96,7 +100,9 @@ You have worked on a feature in your branch (in your fork)
and are now ready to
1. Make sure your branch sits on top of `master`; this ensures the
reviewer/merger will need only minimal effort to integrate your work by
fast-fowarding `master`. You achieve this by running, from your branch:
+ ```
git rebase upstream/master
+ ```
(If you are nervous about rebasing, you can always save a pointer to the
branch with e.g. `git branch -b <mybranch>-backup`.)
@@ -108,7 +114,9 @@ You have worked on a feature in your branch (in your fork)
and are now ready to
To reorganize the commits, use:
+ ```
git rebase -i upstream/master
+ ```
This gives you the opportunity to squash (fuse) all spurious commits, and
also edit all messages.
@@ -116,48 +124,61 @@ You have worked on a feature in your branch (in your
fork) and are now ready to
As a simple illustration, consider the case where you have worked on a feature
branch `power-ups` with three commits, and have fallen behind master. The
history may look like this:
+ ```
o [power-ups] forgot *.pyc in .gitignore
o Power-ups fully implemented.
o Started working on power-ups
│ o [master] {upstream/master} Added a Scala program.
o─┘ Longer instructions
o Instructions for attentive readers.
+ ```
The first step is to rebase `power-ups` on top of `upstream/master`:
+ ```
git checkout power-ups
git rebase upstream/master
+ ```
In general, you may have to solve conflicts during the rebasing. When it
completes, the history above now looks like this:
+ ```
o [power-ups] forgot *.pyc in .gitignore
o Power-ups fully implemented.
o Started working on power-ups
o [master] {upstream/master} Added a Scala program.
o Longer instructions
o Instructions for attentive readers.
+ ```
Note how all commits in `power-ups` now sit on top of `master`. The second
step is to organize the commits into logical units. In this example, we have
two spurious commits, and want to reduce the entire feature branch into a
single commit. We achieve this by running:
+ ```
git rebase -i upstream/master
+ ```
This opens your favorite editor (the same that you use to write commit
messages), with the list of commits under consideration:
+ ```
pick 81b466d Started working on power-ups
pick 862e8e4 Power-ups fully implemented.
pick 1810a5c forgot *.pyc in .gitignore
# Rebase 1d73a3f..1810a5c onto 1d73a3f (3 command(s))
# ...
+ ```
(The rest of the file includes instructions on interactive rebasing.) The
oldest commit is on top. To reduce the number of commits, we _squash_ more
recent ones into older ones. We achieve this by rewriting the word `pick` into
`squash` (or just `s`), saving and exiting the editor:
+ ```
pick 81b466d Started working on power-ups
squash 862e8e4 Power-ups fully implemented.
squash 1810a5c forgot *.pyc in .gitignore
+ ```
Git then squashes the commits, and reopens the editor with a concatenation of
the previous commit messages:
+ ```
# This is a combination of 3 commits.
# The first commit message is:
Started working on power-ups
@@ -171,17 +192,22 @@ Git then squashes the commits, and reopens the editor
with a concatenation of th
forgot *.pyc in .gitignore
# Please enter the commit message for your changes.
+ ```
In this case, we throw out everything but the text of the 2nd commit message.
Maybe we take the opportunity to add text describing why power-ups are
important. When done, we save and exit as is usual when editing commit
messages. After this step, the history looks like this:
+ ```
o [power-ups] Power-ups fully implemented.
o [master] Added a Scala program.
o Longer instructions
o Instructions for attentive readers.
+ ```
The history is clean and compact. We can push our work to our fork and open a
pull request:
+ ```
git push origin power-ups
+ ```
(If we had a previous version of the `power-ups` branch in our fork, we can
use `--force` to override it. Remember though to *never* use `--force` outside
of your fork.)
@@ -213,8 +239,10 @@ Merging pull requests is primarily a mechanical process.
Before merging, confirm
2. GitHub conveniently sets up a reference for pull requests. This means
that contrary to what some parts of the Internet will have you believe, you
don't need to add a new remote for every different developer who submits a pull
request. Assuming you want to merge in pull request number 18, do the following:
+ ```
PR=18
git fetch upstream pull/$PR/head:"pr-$PR"
+ ```
This will checkout all the commits in the pull request into a local branch
called `pr-18` (that name is arbitrary).
@@ -222,12 +250,14 @@ Merging pull requests is primarily a mechanical process.
Before merging, confirm
4. If the pull request was not constructed on top of `upstream/master` or if
it had since diverged, 3. above will fail with `Not possible to fast-forward,
aborting.`. You should rebase the branch:
+ ```
git checkout "pr-$PR"
git rebase master
# (fix conflicts, or ask requester to rebase themselves and update the
pull request if too complex)
git checkout master
git merge --ff-only "pr-$PR"
git push upstream master
+ ```
Now the pull request has been merged. GitHub may not have closed it
automatically, though, as the commits have new hashes. You can close it
manually and make a note that the commits are in master, with different hashes.
--
To stop receiving notification emails like this one, please contact
rab...@apache.org.
