Change Details

Refs T13546 When using `arc land` in a mercurial repository (with `history.immutable = false`) the resulting working state is not currently expected: 1. The `--onto` bookmark will not have advanced to the newly pushed commit(s) 2. The working directory will typically be the old `--onto` changeset This change updates the behavior which should usually be generally expected: 1. Advance the `--onto` bookmarks, which could be accomplished by `hg pull -B [bookmark1] -B [bookmark2] ...` after landing (though there's a window of opportunity that this would pull additional changes down, but this would likely be fine in most cases?) 2. During the merge/rebase, if the pre-workflow local state's active commit is merged/rebased then track that commit for use in `reconcileLocalState()`. During `reconcileLocalState()` update the working directory to the new commit (or onto-marker bookmark if applicable) as long as there was only a single onto-marker destination. If the working directory is landed onto multiple destinations then the desired updated state is ambiguous.

Refs T13546 When using `arc land` in a mercurial repository (with `history.immutable = false`) the resulting working state is not currently expected: 1. The `--onto` bookmark will not have advanced to the newly pushed commit(s) 2. The working directory will typically be the old `--onto` changeset This change updates the behavior which should usually be generally expected: 1. Advance the `--onto` bookmarks, which could be accomplished by `hg pull -B [bookmark1] -B [bookmark2] ...` after landing (though there's a window of opportunity that this would pull additional changes down, but this would likely be fine in most cases?) 2. During the merge/rebase, if the pre-workflow local state's active commit is merged/rebased then track that commit for use in `reconcileLocalState()`. During `reconcileLocalState()` update the working directory to the new commit (or onto-marker bookmark if applicable) as long as there was only a single onto-marker destination. If the working directory is landed onto multiple destinations then the desired updated state is ambiguous. I also ran into when trying to land a diff which consists of multiple local commits, where the first commit adds a new file and the second one modifies that file. The issue appears to be that the merge/rebase is attempting to only rebase the head commit for the diff without it's ancestors, which results in the rebase failing to apply cleanly. There is an issue with the `hg log` format used to select the commits for the diff. I updated this format so that all commits for the diff end up being selected. This uncovered another issue with the merge/rebase command being used with multiple commits which is improperly ordered resulting in an attempt to rebase an empty revision set. I flipped the ordering for the specified revision set so that it ends up including all commits in the correct range.

Refs T13546 When using `arc land` in a mercurial repository (with `history.immutable = false`) the resulting working state is not currently expected: 1. The `--onto` bookmark will not have advanced to the newly pushed commit(s) 2. The working directory will typically be the old `--onto` changeset This change updates the behavior which should usually be generally expected: 1. Advance the `--onto` bookmarks, which could be accomplished by `hg pull -B [bookmark1] -B [bookmark2] ...` after landing (though there's a window of opportunity that this would pull additional changes down, but this would likely be fine in most cases?) 2. During the merge/rebase, if the pre-workflow local state's active commit is merged/rebased then track that commit for use in `reconcileLocalState()`. During `reconcileLocalState()` update the working directory to the new commit (or onto-marker bookmark if applicable) as long as there was only a single onto-marker destination. If the working directory is landed onto multiple destinations then the desired updated state is ambiguous. I also ran into when trying to land a diff which consists of multiple local commits, where the first commit adds a new file and the second one modifies that file. The issue appears to be that the merge/rebase is attempting to only rebase the head commit for the diff without it's ancestors, which results in the rebase failing to apply cleanly. There is an issue with the `hg log` format used to select the commits for the diff. I updated this format so that all commits for the diff end up being selected. This uncovered another issue with the merge/rebase command being used with multiple commits which is improperly ordered resulting in an attempt to rebase an empty revision set. I flipped the ordering for the specified revision set so that it ends up including all commits in the correct range.