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 f27cbd4  Updated Contributing: Git guidelines (markdown)
f27cbd4 is described below

commit f27cbd459358584f18480fac65a546ed90e276b8
Author: rodric rabbah <rod...@gmail.com>
AuthorDate: Fri Mar 2 13:29:21 2018 -0500

    Updated Contributing: Git guidelines (markdown)
---
 Contributing:-Git-guidelines.md | 30 ------------------------------
 1 file changed, 30 deletions(-)

diff --git a/Contributing:-Git-guidelines.md b/Contributing:-Git-guidelines.md
index 3d54ad7..5cc0264 100644
--- a/Contributing:-Git-guidelines.md
+++ b/Contributing:-Git-guidelines.md
@@ -72,16 +72,12 @@ 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)).
 
@@ -100,9 +96,7 @@ 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`.)
 
@@ -114,9 +108,7 @@ 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.
 
@@ -124,61 +116,48 @@ 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
@@ -192,22 +171,17 @@ 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.)
 
@@ -239,10 +213,8 @@ 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).
 
@@ -250,14 +222,12 @@ 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.

Reply via email to