Update revision after rebase without reopening review

We often encounter situations in which we have to rebase a branch because the base branch changed. Many times the new diff, which is sent to differential, contains no changes relative to the previous diff. Phabricator will always reset the revision to “needs review”, though.
This creates quite the overhead for us, because reviewers have to go through many previously accepted revisions and figure out why the revision was changed and if it can be accepted again.

Is there anything that could be done so updating a revision with a diff that is identical to the previous one does not reopen a review?

You don’t need to update revisions when an incidental rebase occurs, and generally should not.

If we rebase and don’t update the revision, then arc won’t be able to tell which revision belongs to the branch when running arc land. We usually run arc land --onto $TARGET $BRANCH.

I can’t reproduce that.

$ arc land --onto master rebase1
 TARGET  Landing onto "master", selected with the "--onto" flag.
 REMOTE  Using remote "origin", the default remote under Git.
 FETCH  Fetching "origin/master"...
# Request received by "local.phacility.net", forwarding to cluster host "local.phacility.net".
# Acquiring read lock for repository "spellbook" on device "local.phacility.net"...
# Acquired read lock immediately.
# Device "local.phacility.net" is already a cluster leader and does not need to be synchronized.
# Cleared to fetch on cluster host "local.phacility.net".
This commit will be landed:

      - 1c4d62f Rebase Test 1

Landing revision 'D118: Rebase Test 1'...

Note that 1c4d62f is a rebased version of the change on the revision itself:

Screen Shot 2020-01-21 at 10.10.30 AM

I tested this with a couple of revisions again and for most branches arc actually accepts the rebased branch without updating the revision. For 2 out of 8 branches though it didn’t work. One of them went like this:

First I ran arc land as usual:

 TARGET  Landing onto "master", selected with the "--onto" flag.
 REMOTE  Using remote "origin", the default remote under Git.
 FETCH  Fetching "origin/master"...
These commits will be landed:

      - 84a1939 remove unnessasary styles
      - edfe8fa add the casper theme and edit it for cmp

Usage Exception: arc can not identify which revision exists on branch 'origin/issues/6756'. Update the revision with recent changes to synchronize the branch name and hashes, or use 'arc amend' to amend the commit message at HEAD, or use '--revision <id>' to select a revision explicitly.

so I updated the revision:

$ arc diff master --update D543

    You don't own revision D543: "Content/Pages Style #6756". Normally, you
    should only update revisions you own. You can "Commandeer" this revision
    from the web interface if you want to become the owner.
    Update this revision anyway? [y/N] y

No lint engine configured for this project.
Running unit tests...
No unit test engine is configured for this project.
 SKIP STAGING  No staging area is configured for this repository.
Updated an existing Differential revision:
        Revision URI: https://phabricator.example.com/D543

Included changes:

But when comparing the latest changes, phabricator tells me there are no changes:

Now arc is able to map the branch to a revision once more:

 TARGET  Landing onto "master", selected with the "--onto" flag.
 REMOTE  Using remote "origin", the default remote under Git.
 FETCH  Fetching "origin/master"...
These commits will be landed:

      - 84a1939 remove unnessasary styles
      - edfe8fa add the casper theme and edit it for cmp

    This branch has revision 'D543: Content/Pages Style #6756' but you are
    not the author. Land this revision by Jeremy? [y/N] y


The revision you are landing ("D543: Content/Pages Style #6756") has not been
"Accepted" by reviewers.

    Land revision in the wrong state? [y/N] N

Usage Exception: User aborted the workflow.

What specific steps can I take to put a repository in a state where arc land can not identify the revision? This looks like it may be a bug, perhaps with the revision lookup rules interacting with revisions you don’t own. If it isn’t a bug, the messaging could probably be more clear.

The output of arc which when the working copy is in one of these states, while you are on the branch you intend to land, may also shed light on the situation.

In the very short term, I think arc land --onto master --revision X branch-name may work, and represents a shorter path than arc diff --update X + arc land --onto master branch-name. However, the expectation is that you should not need to provide an explicit revision ID in this workflow.

Unfortunately I did not have the chance to land branches to which this issue applies and therefore can not provide more information just yet. I will give an update as soon as possible.

@epriestley This is the output I got for a rebased branch. I did not yet update the revision, in case there is more info I could provide.

$ arc which master
To identify the repository associated with this working copy, arc followed this process:

    Configuration value "repository.callsign" is empty.

    This repository has no VCS UUID (this is normal for git/hg).

    The remote URI for this working copy is

    Found a unique matching repository.

This working copy is associated with the Example repository.

If you run 'arc diff master', changes between the commit:

    673a09128629c062  build layout for library category #6775

...and the current working copy state will be sent to Differential, because
it is the merge-base of the explicitly specified base commit 'master' and

You can see the exact changes that will be sent by running this command:

    $ git diff 673a09128629c062..HEAD

These commits will be included in the diff:

    acae00e90ece49de  implement player page

These Differential revisions match the changes in this working copy:

    (No revisions match.)

Since there are no revisions in Differential which match this working copy, a
new revision will be created if you run 'arc diff master'.

(If it’s helpful, you can use arc land --hold ... to do everything arc land ... would do, but not push any changes to the remote.)

I think this probably occurs because the tree hash which phabricator is using to match against revisions can change after a rebase. We worked around our problem by turning sticky reviews back on. This way we can update revisions after they have been accepted, but we have to give more responsibility to the authors.