... | ... | @@ -62,10 +62,11 @@ Do this before you commit them! |
|
|
## Workflow with validate
|
|
|
|
|
|
|
|
|
All changes to GHC and the libraries need to be [validated](testing-patches) before they can be pushed to the main repositories. Validation can take a while - 30 minutes on a 4-core machine is typical - so ideally you want to be validating changes while you are working in a separate tree. Furthermore, validation uses build settings that are different to the ones you would normally use while developing: it adds more libraries (DPH) and builds extra ways (dynamic libraries), so you don't want to use the same build for validation and ordinary development.
|
|
|
All changes to GHC and the libraries need to be [validated](testing-patches) before they can be pushed to the main repositories. Validation can take a while - 30 minutes on a 4-core machine is typical - so ideally you want to be validating changes while you are working in a separate tree. In fact, there are other compelling reasons to have two trees in your development workflow, one for working in and one for validation:
|
|
|
|
|
|
- validation uses build settings that are different to the ones you would normally use while developing: it adds more libraries (DPH), builds extra ways (dynamic libraries), and builds all the documentation, so you don't want to use the same build for validation and ordinary development. In the development tree we use build settings optimised for development: `-O0 -DDEBUG` for the compiler, minimal libraries and ways so that rebuilding is fast.
|
|
|
|
|
|
So for this we normally use two entirely separate trees, one for developing and one for validating. The development tree uses build settings optimised for development: `-O0 -DDEBUG` for the compiler, minimal libraries and ways so that rebuilding is fast. The validate tree is for validating only.
|
|
|
- Having two trees elimiantes a common source of breakage in the main repository: with one tree it is easy to add new files but forget to commit them. Your tests will work, but the build will be broken for others. If you have to pull your changes into a separate tree for testing, you'll notice the missing files before you push.
|
|
|
|
|
|
|
|
|
The typical workflow is to work in the development tree, pull into the validate tree, validate, and then push from the validate tree. But what if validate fails? There are two options:
|
... | ... | @@ -108,10 +109,14 @@ Now you have `ghc-working` and `ghc-validate` repos, and additionally the `ghc-v |
|
|
|
|
|
How do we move patches from `ghc-working` and `ghc-validate`? There are several options here. One is to just use `sync-all pull working` and do merging as usual. This works fine, but results in extra "merge commits" that aren't particularly helpful and clutter the commit logs and the mailing list. A better approach is to rebase patches before committing. This is done as follows:
|
|
|
|
|
|
1. fetch patches from `ghc-working` into `ghc-validate`: `./sync-all fetch working`
|
|
|
1. merge from working: `./sync-all merge working`
|
|
|
1. rebase onto master: `./sync-all pull --rebase`
|
|
|
1. validate, push
|
|
|
1. Pull from `ghc-working` into `ghc-validate`: `./sync-all pull working`
|
|
|
1. Rebase onto origin/master: `./sync-all pull --rebase`. You may encounter conflicts, in which case git will tell you what to do (usually fix the conflict and then `git rebase --continue` in the appropriate repository), then you can resume with `./sync-all --resume pull --rebase` at the top.
|
|
|
1. Check what you have relative to origin: `./sync-all new`
|
|
|
1. `./validate`
|
|
|
1. if validate went through, `./sync-all push` (you might like to check once more what will be pushed: `./sync-all new`).
|
|
|
|
|
|
|
|
|
If push fails because patches have been pushed by someone else while you were validating, it is acceptable to `git pull --rebase` in that repository and push if there are no conflicts (no need to validate again).
|
|
|
|
|
|
|
|
|
Now, the patches pushed this way are different (have different hashes) from the patches that you originally committed in `ghc-working`, and if you try to pull these patches in `ghc-working` again, confusion and conflicts will ensue. Fortunately there's an easy solution: just rebase again in `ghc-working`, and git will notice that your patches are already upstream and will discard the old versions. It's as simple as
|
... | ... | @@ -124,6 +129,9 @@ Now, the patches pushed this way are different (have different hashes) from the |
|
|
|
|
|
If rebase encounters a conflict at any point, it will tell you what to do. After fixing the conflict and completing the rebase manually, you can then resume the pull with `./sync-all --resume pull --rebase`.
|
|
|
|
|
|
|
|
|
There is a slight tweak to this workflow that you might find more convenient: do a `./sync-all pull --rebase` in the `ghc-working` tree prior to pulling into `ghc-validate`. This lets you fix conflicts in `ghc-working` rather than in `ghc-validate`, and test the resolution before validating. The downside is that you might now have to do a lot of rebuilding in your `ghc-working` tree if there are a lot of changes to pull.
|
|
|
|
|
|
## Contributing patches
|
|
|
|
|
|
|
... | ... | |