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. 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 This is an assortment of fixes or updates to landing behavior while using mercurial **Behavior Changes** 1. Currently, after landing the `--onto` bookmark will not be advanced to the newly pushed commit(s) - This updates so that after pushing commits upstream, onto-marker bookmarks are pulled back from the server to retrieve their updated state 2. Currently, after landing the working directory will typically be the old `--onto` commit - This updates the behavior in the following ways 1. If the starting working state is a commit that is part of a revision being landed, the post-land state will be the newly published commit for that revision 2. If the starting working state is a commit for a tip revision being landed and there is only a single `--onto` target, the post-land state will be the newly published commit and the `--onto` bookmark will be activated, if applicable. If there are multiple `--onto` targets defined (uncommon) then the resulting working state will be the same behavior as before, as the desired behavior for this case is ambiguous. 3. If the starting working state is a commit that is not part of any revision being landed, then the post-land state will be that same commit, activating the same previous bookmark if applicable. **Bugs Fixed** 1. When landing a diff that includes multiple commits, where the non-tip commit adds a file and later commit modifies that file, the land process would fail during rebasing. 2. When landing, the display of what commits are going to be landed only includes the commit hash but should include part of the commit message for easy identification. 3. If errors occur during a rebase while landing, the resulting state is an in-progress rebase. Users will typically not be able to resolve this in-progress rebase and possibly confuse them further as they have to first abort the rebase before trying to clean up. These rebases will now be aborted by arcanist before exiting. 4. If using evolve, landing a non-tip revision would leave behind orphaned commits.

Refs T13546 This is an assortment of fixes or updates to landing behavior while using mercurial **Behavior Changes** When using `arc land` in a mercurial repository (with `history.immutable = false`) the resulting working state is not currently expected:1. Currently, after landing the `--onto` bookmark will not be advanced to the newly pushed commit(s) 1. - This updates so that after pushing commits upstream, The `--onto`onto-marker bookmark will not have advanceds are pulled back from the server to the newly pushed commit(s)retrieve their updated state 2. TheCurrently, after landing the working directory will typically be the old `--onto` changeset This change updates the behavior which should usually be generally expected:ommit - This updates the behavior in the following ways 1. If the starting working state is a commit that is part of a revision being landed, the post-land state will be the newly published commit for that revision 1 2. Advance the `--onto` bookmarksIf the starting working state is a commit for a tip revision being landed and there is only a single `--onto` target, 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,the post-land state will be the newly published commit and the `--onto` bookmark will be activated, if applicable. but this would likely be fine in most cases?)If there are multiple `--onto` targets defined (uncommon) then the resulting working state will be the same behavior as before, as the desired behavior for this case is ambiguous. 2. During the merge/rebase, 3. iIf the pre-workflow localstarting working state's active is a commit is merged/rebased then track that commit for use in `reconcileLocalState()`.that is not part of any revision being landed, 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.then the post-land state will be that same commit, If the workactivating directory is landed onto multiple destinations then the desired updated state is ambiguousthe same previous bookmark if applicable. I also ran into when trying to land a diff which consists of multiple local commits**Bugs Fixed** 1. When landing a diff that includes multiple commits, where the non-tip commit adds a file and later commit modifies that file, the land process would fail during rebasing. 2. When landing, where the first commit adds a new file and the second one modifies that filethe display of what commits are going to be landed only includes the commit hash but should include part of the commit message for easy identification. 3. The issue appears to be that the merge/rebase is attempting to onlyIf errors occur during a rebase the head commit for the diff without it's ancestorswhile landing, whichthe results in the rebase failing to apply cleanlying state is an in-progress rebase. There is an issue with the `hg log` format used to select the commits for the diffUsers will typically not be able to resolve this in-progress rebase and possibly confuse them further as they have to first abort the rebase before trying to clean up. I updated this format so that all commits for the diff end up being selectedThese rebases will now be aborted by arcanist before exiting. 4. 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.If using evolve, I flipped the ordering for the specifiedlanding a non-tip revision set so that it ends up including allwould leave behind orphaned commits in the correct range..