Magic-Mirror/gecko-dev
1
0
Fork 0
mirror of https://github.com/mozilla/gecko-dev.git synced 2024-11-26 06:11:37 +00:00
Code Issues Actions Packages Projects Releases Wiki Activity

Bug 1454350 - simplify devtools docs to use mercurial. r=sole

Browse Source 
MozReview-Commit-ID: 4C65NdlGtzl

--HG--
extra : rebase_source : 331619d8250cdcc71c0a7316839055d1982551b2
This commit is contained in:
Belén Albeza 2018-04-16 14:53:58 +02:00
parent 2d5b10a0b5
commit 21708e7c70
2 changed files with 23 additions and 66 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

62
devtools/docs/contributing/making-prs.md
View File

@ -1,20 +1,17 @@
# 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.
@ -26,12 +23,11 @@ You can also take a look at the [Code Review Checklist](./code-reviews.md) as it
## 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:
@ -45,44 +41,8 @@ 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.
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 will see that `81c4d40e57d3` has been combined with `3bd22d1cc59a`. You can verify this using the `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:
```
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:
< 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.

27
devtools/docs/getting-started/build.md
View File

@ -3,8 +3,6 @@
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
@ -12,25 +10,25 @@ These are the steps we're going to look at:
## 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.
Run:
The very first time you are building Firefox, run:
```bash
./mach bootstrap
./mach configure
./mach build
```
After that first successful build, you can just run:
```bash
./mach build
@ -111,7 +109,6 @@ With pseudocode:
./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.