**Major Changes**
- `arc land X` now means "land X **and all ancestors of X**".
- If you stack changes in `feature1`, `feature2`, etc., branches, `arc land featureN` now lands all of the changes.
- If you stack changes in a single `X` branch, `arc land X` now lands all of the changes in the stack.
- You can also pass multiple refs explicitly: `arc land X Y Z`.
- By default, all changes in a single `land` operation are pushed at once, and the entire operation (more or less) either succeeds or fails atomically. The new `--incremental` flag allows you to push and rebase changes individually instead, and may make it easier to land complex sequences of changes that require some user interaction (like merge conflict resolution) during some of the steps.
**Minor Changes**
- `arc land` now functions when the remote is empty (usually, when you are landing the first change in a new repository).
- The `--delete-remote` flag, which deleted remote bookmarks in Mercurial, has been removed. Future workflows (`arc save` and `arc load`) will provide tools for "saving changes".
- The `--keep-branch` flag is now named `--keep-branches`, to reflect that it may affect multiple branches.
- The `arc.land.onto.default` configuration key is now named `arc.land.onto`. Because `--onto` now accepts multiple arguments, this key now accepts a list of values.
- The `arc.autostash` configuration option is no longer respected by `arc land`. This has been replaced with configurable defaults for prompts. (Answer `y!` when prompted to indicate "always answer `y` to this prompt in the future".)
- `arc land` will now retry if it loses a race to push the remote.
- `arc land` now performs fewer working copy and remote operations, and may execute faster in large repositories.
- `arc land` now performs more branch and history scanning operations, and may execute slower in large repositories.
- After a change lands with a "squash" strategy, all local branches descending from that change are rebased onto the landed version of the change. For example, if you `arc land feature1`, your local `feature2` branch will be automatically rebased.
- The `--squash` and `--merge` flags are now `--strategy squash` and `--strategy merge`, to support modular strategies.
**Changes to `--onto`**
`arc land` may now land a change onto multiple target branches in the remote. You can select this behavior by passing `--onto` multiple times. For example:
```
$ arc land xyz --onto master --onto release-2.3
```
This will merge change `xyz`, then push it onto `master` and `release-2.3` in the remote.
Note that each change passed to `arc land` is merged exactly once, so these two commands are **not** equivalent:
```name="Merge Once, Push to Two Branches"
$ arc land xyz --onto master --onto release-2.3
```
```name="Merge Twice"
$ arc land xyz --onto master --keep-branch
$ arc land xyz --onto release-2.3
```
In the first case, `master` and `release-2.3` are guaranteed to be in exactly the same state after `arc land` exits. In the second case, `xyz` is merged into two different states and the resulting states of `master` and `release-2.3` may differ.
The `arc.land.onto` configuration option now has higher precedence than following Git upstreams. For example, if `arc.land.onto` is configured as `master`, but your local branch `feature1` tracks `origin/alice-feature1`, your change will now land onto `master`, not `alice-feature1`. In all cases, you can explicitly select a branch to land onto with `--onto`, which has the highest precedence.
**New Concept: `--into`**
`arc land` may now merge changes into a state other than the state of the ref or refs it is pushing to. In general, this:
```
$ arc land xyz --into A --onto B
```
...means:
- merge change `xyz` into `A` to create state `xyz1`; then
- push `xyz1` to `B`; then
- delete `xyz` if it's a branch.
Usually, you want `--into` and `--onto` to be the same when you run `arc land`, and the value of `--into` will default to the value of `--onto` if you do not specify a different value explicitly. For example, these commands are broadly equivalent:
```name="Broadly Equivalent: Into defaults to Onto"
$ arc land xyz --into Q --onto Q
$ arc land xyz --onto Q
```
(These commands have different behavior if ref `Q` does not exist; the former invocation is an error.)
In almost all cases, you can ignore these new flags and let `arc` select the default behaviors. However, in special situations, you may want to control the merge behavior in greater detail by using `--into` (or the related flags, `--into-remote <remote>`, `--into-local`, and `--into-empty`). For example, this command:
```
$ arc land xyz --into-remote upstream --into master --onto-remote internal --onto release-1.2.9x
```
...means:
- fetch `upstream/master`;
- merge state `xyz` into it, creating state `xyz1`;
- push state `xyz1` to `internal/release-1.2.9x`;
- delete `xyz` if it's a branch.
These new flags allow specification of "into" behavior in more detail:
- `--into-remote <remote>`: read the "into" ref from a remote other than the "onto" remote.
- `--into-local`: use the local state of the "into" ref instead of fetching it from a remote.
- `--into-empty`: use the empty state as the "into" state. Normally, this is selected automatically when you run `arc land` for the first time in a new repository.