[incubator-openwhisk.wiki] branch master updated: Updated Contributing: Git guidelines (markdown)

[ra...@apache.org]

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 <ro...@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 git@github.com:yourname/incubator-openwhisk
-    ```
 
   3. Add upstream remote:
 
-    ```
     git remote add upstream git@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
rabbah@apache.org.