Bug 1454350 - simplify devtools docs to use mercurial. r=sole
authorBelén Albeza <balbeza@mozilla.com>
Mon, 16 Apr 2018 14:53:58 +0200
changeset 414489 9003972112e3
parent 414488 5f3b781af6a7
child 414490 64cb5a4a986e
push id62904
push userebalazs@mozilla.com
push dateThu, 19 Apr 2018 11:31:14 +0000
treeherderautoland@9003972112e3 [default view] [failures only]
perfherder[talos] [build metrics] [platform microbench] (compared to previous push)
reviewerssole
bugs1454350
milestone61.0a1
first release with
nightly linux32
nightly linux64
nightly mac
nightly win32
nightly win64
last release without
nightly linux32
nightly linux64
nightly mac
nightly win32
nightly win64
Bug 1454350 - simplify devtools docs to use mercurial. r=sole MozReview-Commit-ID: 4C65NdlGtzl
devtools/docs/contributing/making-prs.md
devtools/docs/getting-started/build.md
--- a/devtools/docs/contributing/making-prs.md
+++ b/devtools/docs/contributing/making-prs.md
@@ -1,88 +1,48 @@
 # Creating and sending patches <!--TODO: (in the future: Making Pull Requests)-->
 
-<!-- TODO: this will need to be updated in the future when we move to GitHub -->
-
 ## Creating a patch
 
 To create a patch you need to first commit your changes and then export them to a patch file.
 
-With Mercurial:
-* `hg commit -m 'your commit message'`
-* `hg export > /path/to/your/patch`
-
-With Git, the process is similar, but you first need to add an alias to create Mercurial-style patches. Have a look at [the detailed documentation](https://developer.mozilla.org/en-US/docs/Tools/Contributing#Creating_a_patch_to_check_in).
+```
+hg commit -m 'your commit message'
+hg export > /path/to/your/patch
+```
 
 ## Commit messages
 
-Commit messages should follow the pattern `Bug 1234567 - change description. r=reviewer`
+Commit messages should follow the pattern `Bug 1234567 - change description. r=reviewer`.
 
 First is the bug number related to the patch. Then the description should explain what the patch changes. The last part is used to keep track of the reviewer for the patch.
 
 ## Submitting a patch
 
 Once you have a patch file, add it as an attachment to the Bugzilla ticket you are working on and add the `feedback?` or `review?` flag depending on if you just want feedback and confirmation you're doing the right thing or if you think the patch is ready to land respectively. Read more about [how to submit a patch and the Bugzilla review cycle here](https://developer.mozilla.org/en-US/docs/Developer_Guide/How_to_Submit_a_Patch).
 
 You can also take a look at the [Code Review Checklist](./code-reviews.md) as it contains a list of checks that your reviewer is likely to go over when reviewing your code.
 
 ## Squashing commits
 
-Sometimes you may be asked to squash your commits. Squashing means merging multiple commits into one in case you created multiple commits while working on a bug. Squashing bugs is easy with steps listed below for both git and mercurial.
+Sometimes you may be asked to squash your commits. Squashing means merging multiple commits into one in case you created multiple commits while working on a bug. Squashing bugs is easy!
 
-### With Mercurial:
+We will use the histedit extension for squashing commits in Mercurial. You can check if this extension is enabled in your Mercurial installation following these steps:
 
-We will use the histedit extension for squashing commits in Mercurial. You can check if this extension is enabled in your Mercurial following these steps:
-* Open `.hgrc` (default configuration file of mercurial) located in the home directory on Linux/OSX, using your favourite editor.
+* Open `.hgrc` (Linux/OSX) or `Mercurial.ini` (Windows) –this is the default configuration file of Mercurial– located in your home directory, using your favourite editor.
 * Then add `histedit= ` under the `[extensions]` list present in file, if not present already.
 
 Then, run the following command:
 
 `hg histedit`
 
 You will see something like this on your terminal:
 
 ```
 pick 3bd22d1cc59a 0 "First-Commit-Message"
 pick 81c4d40e57d3 1 "Second-Commit-Message"
 ```
 
-These lines represent your commits. Suppose we want to merge 81c4d40e57d3 to 3bd22d1cc59a. Then replace **pick** in front of 81c4d40e57d3 with **fold** (or simply 'f'). Save the changes.
-
-You will see that 81c4d40e57d3 has been combined with 3bd22d1cc59a. You can verify this using `hg log` command.
-
-You can use fold to as many commits you want and they will be combined with the first commit above them which does not use fold.
-
-### With Git:
-
-To squash commits in git we will use the rebase command. Let's learn the syntax using an example:
-
-`git rebase -i HEAD~2`
-
-Above commands is for rebasing commits.
-* The -i flag is to run rebase in interactive mode.
-* HEAD~2 is to rebase the last two commits.
-
-You can use any number, depending on how many commits you want to rebase. 
-
-After you run that command, an editor will open displaying contents similar to this:
+These lines represent your commits. Suppose we want to merge `81c4d40e57d3` to `3bd22d1cc59a`. Then replace **pick** in front of `81c4d40e57d3` with **fold** (or simply 'f'). Save the changes.
 
-```
-pick 5878025 "First-Commit-Message"
-pick bd1efe7 "Second-Commit-Message"
-```
-
-Suppose you want to merge `bd1efe7` to `5878025`, then replace **pick** with **squash** (or simply 's') and save the changes and close the editor, then a file should open like this:
-
-```
-    # This is a combination of 2 commits.
-    # The first commit's message is:
+You will see that `81c4d40e57d3` has been combined with `3bd22d1cc59a`. You can verify this using the `hg log` command.
 
-    < First-Commit-Message >
-
-    This is the 2nd commit message:
-
-    < Second-Commit-Message >
-
-```
-Write a new commit message (note that this will be a new commit message used for squashed commits). Every line not starting with # above contributes to the commit message.
-
-Save your changes and you are done. You will see that your commits have been squashed and you can verify this using `git log` or `git reflog`.
+You can fold as many commits you want, and they will be combined with the first commit above them which does not use fold.
--- a/devtools/docs/getting-started/build.md
+++ b/devtools/docs/getting-started/build.md
@@ -1,41 +1,39 @@
 # Set up to build Firefox Developer Tools
 
 These are the steps we're going to look at:
 
 * [Getting the code](#getting-the-code)
-  * [using Mercurial](#using-mercurial-hg)
-  * [using Git](#using-git)
 * [Building and running locally](#building-and-running-locally)
   * [Rebuilding](#rebuilding)
   * [Artifact builds](#building-even-faster-with-artifact-builds) for even faster builds
   * [Maybe you don't even need to build](#maybe-you-dont-even-need-to-build)
 
 ## Getting the code
 
-The code is officially hosted on [a Mercurial repository](https://hg.mozilla.org/mozilla-central/). Despair not! There are ways of accessing this via git. We will explain this too.
-
-Either way takes a long time, because the repository is **B I G**. So be prepared to be patient.
-
-### Using Mercurial (hg)
+The code is officially hosted on [a Mercurial repository](https://hg.mozilla.org/mozilla-central/). It takes a long time to clone, because the repository is **B I G**. So be prepared to be patient.
 
 ```bash
 hg clone http://hg.mozilla.org/mozilla-central
 ```
 
-### Using git
-
-There is a tool called [git-cinnabar](https://github.com/glandium/git-cinnabar/) that lets you use git on top of a Mercurial repository. There's a bit of setup involved, so we've written [a script to automate](https://github.com/sole/cinnabarify) installing `git-cinnabar` and obtaining the code.
-
 ## Building and running locally
 
-Whatever method you used to obtain the code, the build step is the same. Fortunately, the Firefox team has made a very good job of automating this with bootstrap scripts and putting [documentation](https://developer.mozilla.org/En/Simple_Firefox_build) together.
+Fortunately, the Firefox team has made a very good job of automating the building process with bootstrap scripts and putting [documentation](https://developer.mozilla.org/En/Simple_Firefox_build) together.
+
+The very first time you are building Firefox, run:
 
-Run:
+```bash
+./mach bootstrap
+./mach configure
+./mach build
+```
+
+After that first successful build, you can just run:
 
 ```bash
 ./mach build
 ```
 
 If your system needs additional dependencies installed (for example, Python, or a compiler, etc), various diagnostic messages will be printed to your screen. Follow their advice and try building again.
 
 Building also takes a long time (specially on slow computers).
@@ -106,12 +104,11 @@ With pseudocode:
 ./mach run
 # 3. you try out things in the browser that opens
 # 4. fully close the browser, e.g. ⌘Q in MacOS
 # 5. edit JS files on the `devtools` folder, save
 # 6. Back to step 2!
 ./mach run
 ```
 
-While not as fast as the average "save file and reload the website" *web development workflow*, or newer workflows such as React's reloading, this can still be quite fast. 
+While not as fast as the average "save file and reload the website" *web development workflow*, or newer workflows such as React's reloading, this can still be quite fast.
 
 And certainly faster than building each time, even with artifact builds.
-