Fix spelling
Summary: Noticed a couple of typos in the docs, and then things got out of hand. Test Plan: - Stared at the words until my eyes watered and the letters began to swim on the screen. - Consulted a dictionary. Reviewers: #blessed_reviewers, epriestley Reviewed By: #blessed_reviewers, epriestley Subscribers: epriestley, yelirekim, PHID-OPKG-gm6ozazyms6q6i22gyam Differential Revision: https://secure.phabricator.com/D18693
This commit is contained in:
committed by
epriestley
parent
4fd9d2d4bb
commit
9bd6a37055
@@ -87,7 +87,7 @@ you to consent. If you are not comfortable with this, do not sign the CLA and
|
||||
do not contribute to Phabricator.
|
||||
|
||||
**Limitation of Liability**: The second benefit the CLA provides is that it
|
||||
makes the terms of your contribition explicitly clear upfront, and it puts us
|
||||
makes the terms of your contribution explicitly clear upfront, and it puts us
|
||||
in a much stronger legal position if a contributor later claims there is
|
||||
ambiguity about ownership of their work. We can point at the document they
|
||||
signed as proof that they consented to our use and understood the terms of
|
||||
@@ -100,7 +100,7 @@ anything we are likely to face, but SCO claimed billions of dollars in damages
|
||||
and the litigation has now been ongoing for more than a decade.
|
||||
|
||||
We want to avoid situations like this in the future by making the terms of
|
||||
contibution explicit upfront.
|
||||
contribution explicit upfront.
|
||||
|
||||
Generally, we believe the terms of the CLA are fair and reasonable for
|
||||
contributors, and that the primary way contributors benefit from contributing
|
||||
@@ -158,7 +158,7 @@ local law.
|
||||
|
||||
If you are unsure, you should speak with your employer or a lawyer. If you
|
||||
contribute code you do not own under the individual CLA, you are exposing
|
||||
yourself to liability. You may also be exposing us to liablity, but we'll have
|
||||
yourself to liability. You may also be exposing us to liability, but we'll have
|
||||
the CLA on our side to show that we were unwilling pawns in your malicious
|
||||
scheme to defraud your employer.
|
||||
|
||||
|
||||
@@ -140,7 +140,7 @@ Additional Resources
|
||||
|
||||
Poor problem descriptions are a common issue in software development and
|
||||
extensively documented elsewhere. Here are some additional resources describing
|
||||
how to describe problems and ask questions effectivey:
|
||||
how to describe problems and ask questions effectively:
|
||||
|
||||
- [[ http://www.catb.org/esr/faqs/smart-questions.html | How To Ask
|
||||
Questions The Smart Way ]], by Eric S. Raymond
|
||||
|
||||
@@ -198,7 +198,7 @@ would technically be English and most English readers would understand the
|
||||
meaning, but no native English speaker would speak or write like this.
|
||||
|
||||
However, some languages have different subject-verb order rules or
|
||||
colloquisalisms, and a word order which transliterates like this may sound more
|
||||
colloquialisms, and a word order which transliterates like this may sound more
|
||||
natural to a native speaker. By translating fragments instead of complete
|
||||
sentences, you lock translators into English word order.
|
||||
|
||||
|
||||
@@ -112,7 +112,7 @@ we'll probably be able to follow them and reproduce the issue ourselves.
|
||||
|
||||
If you can't follow your steps because they depend on information which is not
|
||||
available on a clean instance (for example, a certain config setting), rewrite
|
||||
them to include instrutions to create that information (for example, adjusting
|
||||
them to include instructions to create that information (for example, adjusting
|
||||
the config to the problematic value).
|
||||
|
||||
If you follow your instructions but the issue does not reproduce, the issue
|
||||
@@ -191,7 +191,7 @@ smaller case which reproduces the problem, which might be something like this:
|
||||
- Files like `A`, which have uppercase letters, do not work.
|
||||
|
||||
With a simpler reproduction scenario, you can simplify your steps to be more
|
||||
tailored and mimimal. This will help us pointpoint the issue more quickly and
|
||||
tailored and minimal. This will help us pinpoint the issue more quickly and
|
||||
be more certain that we've understood and resolved it.
|
||||
|
||||
It is more important that steps be complete than that they be simple, and it's
|
||||
|
||||
@@ -225,7 +225,7 @@ Cluster: Notifications
|
||||
Configuring multiple notification hosts is simple and has no pre-requisites.
|
||||
|
||||
With multiple notification hosts, you can survive the loss of any subset of
|
||||
hosts as long as at least one host remains alive. Service may be breifly
|
||||
hosts as long as at least one host remains alive. Service may be briefly
|
||||
disrupted directly after the incident which destroys the other hosts.
|
||||
|
||||
Notifications are noncritical, so this normally has little practical impact
|
||||
|
||||
@@ -31,7 +31,7 @@ although this may change in the future.
|
||||
|
||||
Phabricator applications //can// be partitioned across multiple database
|
||||
masters. This does not provide redundancy and generally does not increase
|
||||
resiliance or resistance to data loss, but can help you scale and operate
|
||||
resilience or resistance to data loss, but can help you scale and operate
|
||||
Phabricator. For details, see
|
||||
@{article:Cluster: Partitioning and Advanced Configuration}.
|
||||
|
||||
|
||||
@@ -212,7 +212,7 @@ $ ./bin/almanac register \
|
||||
For example, you might run this command on `repo001` when using a shared key:
|
||||
|
||||
```
|
||||
$ ./bin/almanac register
|
||||
$ ./bin/almanac register \
|
||||
--device keywarden.mycompany.net \
|
||||
--private-key /path/to/private-key \
|
||||
--identify-as repo001.mycompany.net
|
||||
|
||||
@@ -21,7 +21,7 @@ This configuration is complex, and very few installs will benefit from pursuing
|
||||
it. Phabricator will normally run comfortably with a single database master
|
||||
even for large organizations.
|
||||
|
||||
Partitioning generally does not do much to increase resiliance or make it
|
||||
Partitioning generally does not do much to increase resilience or make it
|
||||
easier to recover from disasters, and is primarily a mechanism for scaling and
|
||||
operational convenience.
|
||||
|
||||
@@ -212,14 +212,14 @@ only one master.
|
||||
|
||||
`persistent` //(bool)// Enables persistent connections. Defaults to off.
|
||||
|
||||
With persitent connections enabled, Phabricator will keep a pool of database
|
||||
With persistent connections enabled, Phabricator will keep a pool of database
|
||||
connections open between web requests and reuse them when serving subsequent
|
||||
requests.
|
||||
|
||||
The primary benefit of using persistent connections is that it will greatly
|
||||
reduce pressure on how quickly outbound TCP ports are opened and closed. After
|
||||
a TCP port closes, it normally can't be used again for about 60 seconds, so
|
||||
rapidly cycling ports can cause resource exuastion. If you're seeing failures
|
||||
rapidly cycling ports can cause resource exhaustion. If you're seeing failures
|
||||
because requests are unable to bind to an outbound port, enabling this option
|
||||
is likely to fix the issue. This option may also slightly increase performance.
|
||||
|
||||
|
||||
@@ -440,7 +440,7 @@ device or devices have up-to-date information.
|
||||
|
||||
When Phabricator can not tell which device in a cluster is a leader, it freezes
|
||||
the cluster because it is possible that some devices have less data and others
|
||||
have more, and if it choses a leader arbitrarily it may destroy some data
|
||||
have more, and if it chooses a leader arbitrarily it may destroy some data
|
||||
which you would prefer to retain.
|
||||
|
||||
To resolve this, you need to tell Phabricator which device has the most
|
||||
|
||||
@@ -100,14 +100,14 @@ A typical `mysql` service configuration looks like this:
|
||||
Service Type: Elasticsearch
|
||||
======================
|
||||
|
||||
The `elasticsearch` sevice type supports these options:
|
||||
The `elasticsearch` service type supports these options:
|
||||
|
||||
| Key | Description |
|
||||
|---|---|
|
||||
| `protocol` | Either `"http"` (default) or `"https"`.
|
||||
| `port` | Elasticsearch TCP port.
|
||||
| `version` | Elasticsearch version, either `2` or `5` (default).
|
||||
| `path` | Path for the index. Defaults to `/phabriator`. Advanced.
|
||||
| `path` | Path for the index. Defaults to `/phabricator`. Advanced.
|
||||
|
||||
A typical `elasticsearch` service configuration looks like this:
|
||||
|
||||
|
||||
@@ -116,7 +116,7 @@ Restart nginx after making your edits, then continue to "Setup" below.
|
||||
|
||||
= Webserver: Configuring lighttpd =
|
||||
|
||||
NOTE: Follow these instructions to use lighttpd. To use Apache or niginx, scroll
|
||||
NOTE: Follow these instructions to use lighttpd. To use Apache or nginx, scroll
|
||||
up to their sections.
|
||||
|
||||
For lighttpd, add a section like this to your lighttpd.conf:
|
||||
@@ -138,7 +138,7 @@ server.modules list:
|
||||
|
||||
Finally, you should run the following commands to enable php support:
|
||||
|
||||
$ sudo apt-get install php5-cgi # for ubuntu; other distros should be similar
|
||||
$ sudo apt-get install php5-cgi # for Ubuntu; other distros should be similar
|
||||
$ sudo lighty-enable-mod fastcgi-php
|
||||
|
||||
Restart lighttpd after making your edits, then continue below.
|
||||
|
||||
@@ -64,7 +64,7 @@ If you host repositories in Phabricator, you should back them up. You can use
|
||||
repository. To back them up, copy them elsewhere.
|
||||
|
||||
You can also just clone them and keep the clones up to date, or use
|
||||
{nav Add Mirror} to have the mirror somewhere automatically.
|
||||
{nav Add Mirror} to have them mirror somewhere automatically.
|
||||
|
||||
|
||||
Restore: Hosted Repositories
|
||||
|
||||
@@ -80,7 +80,7 @@ Format: Raw Data
|
||||
================
|
||||
|
||||
The `raw` storage format is automatically selected for all newly uploaded
|
||||
file data if no key is makred as the `default` key in the keyring. This is
|
||||
file data if no key is marked as the `default` key in the keyring. This is
|
||||
the behavior of Phabricator if you haven't configured anything.
|
||||
|
||||
This format stores raw data without modification.
|
||||
@@ -137,7 +137,7 @@ To change the format of an individual file, run this command:
|
||||
phabricator/ $ ./bin/files encode --as <format> F123 [--key <key>]
|
||||
```
|
||||
|
||||
This will change the storage format of the sepcified file.
|
||||
This will change the storage format of the specified file.
|
||||
|
||||
|
||||
Verifying Storage Formats
|
||||
|
||||
@@ -21,7 +21,7 @@ Configuring Retention Policies
|
||||
|
||||
You can reconfigure the data retention policies for most collectors.
|
||||
|
||||
The default retention polcies should be suitable for most installs. However,
|
||||
The default retention policies should be suitable for most installs. However,
|
||||
you might want to **decrease** retention to reduce the amount of disk space
|
||||
used by some high-volume log that you don't find particularly interesting, or
|
||||
to adhere to an organizational data retention policy.
|
||||
|
||||
@@ -11,7 +11,7 @@ For example, when we write a new application, it usually adds several new API
|
||||
methods and may update older methods.
|
||||
|
||||
This document discusses API stability and how to minimize disruption when
|
||||
transitionig between API versions.
|
||||
transitioning between API versions.
|
||||
|
||||
|
||||
Method Statuses
|
||||
|
||||
@@ -131,7 +131,7 @@ Generally, this column can help pinpoint these kinds of problems:
|
||||
- Unbatched queries which should be batched (see
|
||||
@{article:Performance: N+1 Query Problem}).
|
||||
- Opportunities to improve performance with caching.
|
||||
- General goofiness in how service calls are woking.
|
||||
- General goofiness in how service calls are working.
|
||||
|
||||
If the services tab looks fine, and particularly if a page is slow but the
|
||||
"All Services" cost is small, that may indicate a problem in PHP. The best
|
||||
|
||||
@@ -34,7 +34,7 @@ Phabricator will need substantial time to process it, it will take a long time
|
||||
to download over the network, and your browser will probably not be able to
|
||||
render it especially quickly.
|
||||
|
||||
We may be able to improve perfomance in some cases, but Phabricator is not
|
||||
We may be able to improve performance in some cases, but Phabricator is not
|
||||
magic and can not wish away real complexity. The best solution to these problems
|
||||
is usually to find another way to solve your problem: for example, maybe the
|
||||
100MB document can be split into several smaller documents.
|
||||
@@ -51,7 +51,7 @@ The upstream will be less able to help resolve unusual workloads with high
|
||||
inherent complexity, like these:
|
||||
|
||||
- {icon times, color=red} A 100MB wiki page takes a long time to render.
|
||||
- {icon times, color=red} A turing-complete simulation of Conway's Game of
|
||||
- {icon times, color=red} A Turing-complete simulation of Conway's Game of
|
||||
Life implemented in 958,000 Herald rules executes slowly.
|
||||
- {icon times, color=red} Uploading an 8GB file takes several minutes.
|
||||
|
||||
|
||||
@@ -127,7 +127,7 @@ may have briefly been down, or some configuration wasn't quite right, or the
|
||||
daemons were killed halfway through the work.
|
||||
|
||||
These commits will retry eventually and usually succeed, but some of the retry
|
||||
time limits are very conserative (up to 24 hours) and you might not want to
|
||||
time limits are very conservative (up to 24 hours) and you might not want to
|
||||
wait that long.
|
||||
|
||||
In the Daemon console, temporarily failures usually look like tasks in the
|
||||
@@ -137,7 +137,7 @@ waiting to retry these tasks.
|
||||
|
||||
In the daemon log, these temporary failures might have created log entries, but
|
||||
might also not have. For example, if the failure was rooted in a network issue
|
||||
that probably will create a log entry, but if the faiulre was rooted in the
|
||||
that probably will create a log entry, but if the failure was rooted in the
|
||||
daemons being abruptly killed that may not create a log entry.
|
||||
|
||||
You can follow the instructions from "Handling Permanent Failures" above to
|
||||
@@ -167,7 +167,7 @@ Forced Parsing
|
||||
==============
|
||||
|
||||
In rare cases, the actual tasks may be lost from the task queue. Usually, they
|
||||
have been stolen by gremlins or spritied away by ghosts, or someone may have
|
||||
have been stolen by gremlins or spirited away by ghosts, or someone may have
|
||||
been too ambitious with running manual SQL commands and deleted a bunch of
|
||||
extra things they shouldn't have.
|
||||
|
||||
@@ -226,7 +226,7 @@ General Tips
|
||||
============
|
||||
|
||||
Broadly, `bin/repository` contains several useful debugging commands which
|
||||
let you figure out where failures are occuring. You can add the `--trace` flag
|
||||
let you figure out where failures are occurring. You can add the `--trace` flag
|
||||
to any command to get more details about what it is doing. For any command,
|
||||
you can use `help` to learn more about what it does and which flag it takes:
|
||||
|
||||
|
||||
@@ -88,7 +88,7 @@ that you're looking at a problem which is deeper in the stack, and you need
|
||||
to go down further to identify and understand it.
|
||||
|
||||
Conversely, if the "Wall Time (Exclusive)" column is large, or the children
|
||||
of a call are all cheap, there's probably something expesive happening in the
|
||||
of a call are all cheap, there's probably something expensive happening in the
|
||||
call itself.
|
||||
|
||||
The "Count" column can also sometimes tip you off that something is amiss, if
|
||||
|
||||
@@ -122,7 +122,7 @@ Each service has a name, and may have properties and bindings.
|
||||
**Bindings**: Bindings are connections between services and interfaces. They
|
||||
tell callers which devices host a named service.
|
||||
|
||||
**Networks**: Networks allow Almanac to distingiush between addresses on
|
||||
**Networks**: Networks allow Almanac to distinguish between addresses on
|
||||
different networks, like VPNs vs the public internet.
|
||||
|
||||
If you have hosts in different VPNs or on private networks, you might have
|
||||
|
||||
@@ -3,7 +3,7 @@
|
||||
|
||||
Guide to Arcanist, a command-line interface to Phabricator.
|
||||
|
||||
Arcanists provides command-line access to many Phabricator tools (like
|
||||
Arcanist provides command-line access to many Phabricator tools (like
|
||||
Differential, Files, and Paste), integrates with static analysis ("lint") and
|
||||
unit tests, and manages common workflows like getting changes into Differential
|
||||
for review.
|
||||
|
||||
@@ -169,7 +169,7 @@ Normally, you will be presented with lint messages as you are sending code for
|
||||
review. In that context, the severities behave like this:
|
||||
|
||||
- `error` When a file contains lint errors, they are always reported. These
|
||||
are intended to be severe problems, like a syntax error. Unresoved lint
|
||||
are intended to be severe problems, like a syntax error. Unresolved lint
|
||||
errors require you to confirm that you want to continue.
|
||||
- `warning` When a file contains warnings, they are reported by default only
|
||||
if they appear on lines that you have changed. They are intended to be
|
||||
|
||||
@@ -61,7 +61,7 @@ To export a group of events:
|
||||
- Example: All events tagged `#meetup`.
|
||||
- Select the {nav Use Results... > Export Query as .ics} action to turn
|
||||
the query into an export.
|
||||
- Name the export with a descritive name.
|
||||
- Name the export with a descriptive name.
|
||||
- Select a policy mode for the export (see below for discussion).
|
||||
- Click {nav Create New Export} to finish the process.
|
||||
|
||||
|
||||
@@ -10,7 +10,7 @@ IMPORTANT: Calendar is a prototype application. See
|
||||
@{article:User Guide: Prototype Applications}.
|
||||
|
||||
You can import events into Phabricator to other calendar applications or from
|
||||
`.ics` files. This document will guide you through how to importe event data
|
||||
`.ics` files. This document will guide you through how to import event data
|
||||
into Phabricator.
|
||||
|
||||
When you import events from another application, they can not be edited in
|
||||
|
||||
@@ -37,7 +37,7 @@ Editing Objects
|
||||
|
||||
To edit objects, pass a list of transactions and use `objectIdentifier` to
|
||||
specify which object to apply them to. You can normally pass an ID or PHID,
|
||||
and many applicaitons also allow you to pass a monogram (for example, you can
|
||||
and many applications also allow you to pass a monogram (for example, you can
|
||||
edit a task by passing `T123`).
|
||||
|
||||
|
||||
|
||||
@@ -147,7 +147,7 @@ Activate the Repository
|
||||
=======================
|
||||
|
||||
Now that any URIs have been configured, activate the repository with another
|
||||
call to `diffusion.repository.edit`. This time, modify the existing repostitory
|
||||
call to `diffusion.repository.edit`. This time, modify the existing repository
|
||||
instead of creating a new one:
|
||||
|
||||
```
|
||||
|
||||
@@ -151,7 +151,7 @@ vcs-user ALL=(daemon-user) SETENV: NOPASSWD: /path/to/x, /path/to/y, ...
|
||||
|
||||
This is just a template. In the real configuration file, you need to:
|
||||
|
||||
- Replace `www-user`, `dameon-user` and `vcs-user` with the correct
|
||||
- Replace `www-user`, `daemon-user` and `vcs-user` with the correct
|
||||
usernames for your system.
|
||||
- List every binary that these users need access to, as described above.
|
||||
- Make sure each binary path is the full path to the correct binary location
|
||||
|
||||
@@ -121,7 +121,7 @@ It is normally a good idea to leave this protection enabled because most
|
||||
scalable workflows rarely rewrite repository history and it's easy to make
|
||||
mistakes which are expensive to correct if this protection is disabled.
|
||||
|
||||
If you do occasionally need to rewite published history, you can treat this
|
||||
If you do occasionally need to rewrite published history, you can treat this
|
||||
option like a safety: disable it, perform required rewrites, then enable it
|
||||
again.
|
||||
|
||||
@@ -148,7 +148,7 @@ Repositories can be deactivated. Deactivating a repository has these effects:
|
||||
- the repository will be hidden from view in default queries.
|
||||
|
||||
When repositories are created for the first time, they are deactivated. This
|
||||
gives you an opportuinty to customize settings, like adjusting policies or
|
||||
gives you an opportunity to customize settings, like adjusting policies or
|
||||
configuring a URI to observe. You must activate a repository before it will
|
||||
start working normally.
|
||||
|
||||
@@ -177,7 +177,7 @@ The **Policies** section of the management interface allows you to review and
|
||||
manage repository access policies.
|
||||
|
||||
You can configure granular access policies for each repository to control who
|
||||
can view, clone, administate, and push to the repository.
|
||||
can view, clone, administrate, and push to the repository.
|
||||
|
||||
|
||||
Policies: View
|
||||
@@ -302,7 +302,7 @@ Actions
|
||||
The **Actions** panel can configure notifications and publishing behavior.
|
||||
|
||||
Normally, Phabricator publishes notifications when it discovers new commits.
|
||||
You can disable publishing for a repository by turning off **Publish/Noitfy**.
|
||||
You can disable publishing for a repository by turning off **Publish/Notify**.
|
||||
This will disable notifications, feed, and Herald (including audits and build
|
||||
plans) for this repository.
|
||||
|
||||
@@ -347,7 +347,7 @@ Commit Identifiers
|
||||
==================
|
||||
|
||||
Diffusion uses repository identifiers and information about the commit itself
|
||||
to generate globally unique identifers for each commit, like `rE12345`.
|
||||
to generate globally unique identifiers for each commit, like `rE12345`.
|
||||
|
||||
Each commit may have several identifiers:
|
||||
|
||||
|
||||
@@ -20,7 +20,7 @@ is hosted elsewhere (like GitHub or Bitbucket) and track updates to the remote
|
||||
repository. This will create a read-only copy of the repository in Phabricator.
|
||||
|
||||
**Mirror Repositories**: Phabricator can publish any repository to mirrors,
|
||||
overwiting them with an exact copy of the repository that stays up to date as
|
||||
overwriting them with an exact copy of the repository that stays up to date as
|
||||
the source changes. This works with both local repositories that Phabricator is
|
||||
hosting and remote repositories that Phabricator is observing.
|
||||
|
||||
@@ -293,7 +293,7 @@ For builtin URIs in //Read Only// or //Read/Write// mode, the most
|
||||
human-readable URI defaults to //Always// and the others default to //Never//.
|
||||
|
||||
**Always**: This URI will be shown to users as a clone/checkout URI. You can
|
||||
add URIs in this mode to cutomize exactly what users are shown.
|
||||
add URIs in this mode to customize exactly what users are shown.
|
||||
|
||||
**Never**: This URI will not be shown to users. You can hide less-preferred
|
||||
URIs to guide users to the URIs they should be using to interact with the
|
||||
|
||||
@@ -151,7 +151,7 @@ thousands of hosts in hundreds of pools, and far beyond that with a little
|
||||
work.
|
||||
|
||||
Drydock is intended to solve resource management problems at very large scales
|
||||
and minimzes blocking operations, locks, and artificial sequencing. Drydock is
|
||||
and minimizes blocking operations, locks, and artificial sequencing. Drydock is
|
||||
designed to fully utilize an almost arbitrarily large pool of resources and
|
||||
improve performance roughly linearly with available hardware.
|
||||
|
||||
|
||||
@@ -47,7 +47,7 @@ operations on trusted hosts. For additional discussion, see
|
||||
|
||||
This also broadly prevents Drydock from surprising you by coming up with a
|
||||
valid but unintended solution to an allocation problem which runs some
|
||||
operation on resources that are techincally suitable but not desirable. For
|
||||
operation on resources that are technically suitable but not desirable. For
|
||||
example, you may not want your Android builds running on your iPhone build
|
||||
tier, even if there's no technical reason they can't.
|
||||
|
||||
|
||||
@@ -141,7 +141,7 @@ host which is not on a privileged subnet. For example, use a
|
||||
Even if the host is not privileged, many Drydock processes have some level of
|
||||
privilege (enabling them to clone repositories, or report test results back to
|
||||
Phabricator). Be aware that tests can hijack credentials they are run with,
|
||||
and potentialy hijack credentials given to other processes on the same hosts.
|
||||
and potentially hijack credentials given to other processes on the same hosts.
|
||||
You should use credentials with a minimum set of privileges and assume all
|
||||
processes on a host have the highest level of access that any process on the
|
||||
host has.
|
||||
|
||||
@@ -34,7 +34,7 @@ objects, which will also affect their ability to take inline actions in the
|
||||
comment form if you're working in an application which supports comments. This
|
||||
can streamline the edit workflow for less experienced users.
|
||||
|
||||
Anyone can use prefiling, but you must have permission to configure an
|
||||
Anyone can use prefilling, but you must have permission to configure an
|
||||
application in order to modify the application's forms. By default, only
|
||||
administrators can configure applications.
|
||||
|
||||
|
||||
@@ -126,7 +126,7 @@ match the content. You can use these together to express conditions like
|
||||
For example, if you want to match revisions which add or remove calls to a
|
||||
"muffinize" function, //but only in JS files//, you can set the value to
|
||||
`["/\\.js$/", "/muffinize/"]` or similar. This condition is satisfied only
|
||||
when the filename matches the first expression and the conent matches the
|
||||
when the filename matches the first expression and the content matches the
|
||||
second expression.
|
||||
|
||||
**Another Herald rule**: you can create Herald rules which depend on other
|
||||
|
||||
@@ -1,7 +1,7 @@
|
||||
@title Search User Guide: Shortcuts
|
||||
@group userguide
|
||||
|
||||
Command reference for global search shorcuts.
|
||||
Command reference for global search shortcuts.
|
||||
|
||||
Overview
|
||||
========
|
||||
|
||||
@@ -24,7 +24,7 @@ including these paths:
|
||||
|
||||
Any files in those directories are considered to be part of the package, and
|
||||
you can now conveniently refer to them (for example, in a Herald rule) by
|
||||
refering to the package instead of copy/pasting a huge regular expression
|
||||
referring to the package instead of copy/pasting a huge regular expression
|
||||
into a bunch of places.
|
||||
|
||||
If new source files are later added, or the scope of the package otherwise
|
||||
|
||||
@@ -14,7 +14,7 @@ a name and an icon, and may optionally have members.
|
||||
|
||||
For example, you can create projects to provide:
|
||||
|
||||
- **Organization**: Create a project to represent a product or initative,
|
||||
- **Organization**: Create a project to represent a product or initiative,
|
||||
then use it to organize related work.
|
||||
- **Groups**: Create a project to represent a group of people (like a team),
|
||||
then add members of the group as project members.
|
||||
|
||||
@@ -366,7 +366,7 @@ can be found on the date stamp of any transaction/comment):
|
||||
|
||||
T123#412 # Link to comment id #412 of task T123
|
||||
|
||||
See the Phabricator configuraton setting `remarkup.ignored-object-names` to
|
||||
See the Phabricator configuration setting `remarkup.ignored-object-names` to
|
||||
modify this behavior.
|
||||
|
||||
= Embedding Objects
|
||||
|
||||
@@ -87,7 +87,7 @@ view show the results you most often want.
|
||||
|
||||
You can share queries with other users by sending them the URL. This will run
|
||||
the same query for them with all the parameters you've set (they may see
|
||||
different results than you do, because they may not have the same permisions).
|
||||
different results than you do, because they may not have the same permissions).
|
||||
|
||||
|
||||
Typeaheads
|
||||
|
||||
@@ -70,7 +70,7 @@ spaces exist. This simplifies the UI for users with limited access.
|
||||
Space Policies
|
||||
==============
|
||||
|
||||
Briefly, spacess affect policies like this:
|
||||
Briefly, spaces affect policies like this:
|
||||
|
||||
- Spaces apply their view policy to all objects inside the space.
|
||||
- Space policies are absolute, and stronger than all other policies. A
|
||||
|
||||
@@ -73,7 +73,7 @@ The **Mailing List** role for an account can not be changed after the account
|
||||
is created.
|
||||
|
||||
Some options can be configured for mailing lists by browsing to the list user's
|
||||
profile and clicking {nav Edit Settings}. You can change the addresss for a
|
||||
profile and clicking {nav Edit Settings}. You can change the address for a
|
||||
list by editing "Email Addresses" here, choose the language and format for
|
||||
email the list receives, and customize which actions the list is notified about.
|
||||
|
||||
|
||||
Reference in New Issue
Block a user