See [File arguments vs. target arguments](🔗) for the normal techniques for telling Pants what to run on.
See [Project introspection](🔗) for queries that you can run and then pipe into another Pants run, such as running over certain target types.
## Running over changed files with `
Because Pants understands Git, it can find which files have changed since a certain commit through the `
For example, to lint all uncommitted files, run:
To run against another branch, run:
By default, `
--changed-since` will only run over files directly changed. Often, though, you will want to run over any [dependees](🔗) of those changed files, meaning any targets that depend on the changed files. Use `
--changed-dependees=direct` or `
--changed-dependees=transitive` for this:
Using a version control system other than Git?
Please message us on Slack or open a GitHub issue (see [Community](🔗)). We would be happy to look into adding support for your VCS, such as helping you with a PR to add support.
## Tags: annotating targets
Every target type has a field called `
tags`, which allows you to add a sequence of strings. The strings can be whatever you'd like, such as `
You can then filter by tags with the global `
--tag` [option](🔗), like this:
To exclude certain tags, prefix with a `
You can even combine multiple includes and excludes:
The global option `
--spec-files` allows you to pass a file containing target addresses and/or file names/globs to Pants.
Each entry must be separated by a new line.
Tip: centralized allow/block lists
tags` are useful for _decentralized_ allow/block lists, `
--spec-files` is useful when you want to define one single list of targets or files.
## Piping to other Pants runs
To pipe a Pants run, use your shell's `
|` pipe operator and `
You can, of course, pipe multiple times:
Alternative: use `
Sometimes, you may want to reuse the output of a Pants run for multiple subsequent Pants runs. Rather than repeating `
xargs` multiple times, you can generate a file through stdout redirection and `
If you don't want to save the output to an actual file—such as to not pollute version control—you can use a variable and a named pipe:
## Sharding the input targets
You can leverage shell piping to partition the input targets into multiple shards.
For example, to split your Python tests into 10 shards, and select shard 0: