Change Details

Refs T13546 **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 **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 **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.