**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. The new `--incremental` flag allows you to push them individually instead, and may make it easier to land complex sequences of changes that require some user interaction (like conflict resolution).
**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.
- 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.
**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.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.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.