Page MenuHomePhabricator

If arc diff is run twice on exact same commit, will upload new diff to differential
Closed, WontfixPublic

Description

For example, see http://fab.wmflabs.org/D26 . I verified this can be reproduced as follows:

Do a commit

arc diff (creates differential)
git reset --hard original_git_hash (Phabricator shows this under local commits)
arc diff

Although the local commit hash (and thus parent, message, and code) are exactly the same, it will update a new diff (after asking for a message). Gerrit will decline to change the server state in this case.

Originally reported by qchris at http://fab.wmflabs.org/T228

Event Timeline

mattflaschen raised the priority of this task from to Needs Triage.
mattflaschen updated the task description. (Show Details)
mattflaschen added projects: Arcanist, Wikimedia.
mattflaschen added subscribers: mattflaschen, qgil.

This is intended: it doesn't do any damage, and the user explicitly told us to do it. They may reasonably want to pick up side effects in the environment which are not captured in the commit hash (for example, a change to configuration, unit tests, or lint). They may also want to test Herald rules. In particular, I do this routinely during development.

While we shouldn't privilege development workflows over user workflows, I can't recall regular users ever reporting difficulty with this.

We could issue a warning ("You didn't change anything, are you sure you want to update with the same changes?") but I'm not sure when a user would try to do this without understanding what they were doing. Can you provide some context? Specifically, where in your workflow would you run arc diff on changes which might or might not have been sent for review already without knowing?

Specifically, where in your workflow would you run arc diff on changes which might or might not have been sent for review already without knowing?

I agree it's not something that will happen a lot. The most realistic scenario is when you simply forgot you already ran arc diff.

Specifically, where in your workflow would you run arc diff on changes which might or might not have been sent for review already without knowing?

Certainly, you could've forgotten you've done it. Alternately, you could be attempting to submit a patchset with a rebase-based workflow, in which you (re)submit every patch. The behaviour in this case, where changed patches get --update'd, and unchanged patches generate entirely new revisions, is surprising to say the least.

I'd say testing Herald rules is definitely a very niche corner case, and if I'm honest, am not 100% sure why you'd want to resubmit in the 'environment side-effects' case. Is this to cover a workflow where such revisions are rejected and then abandoned?

The behaviour in this case, where changed patches get --update'd, and unchanged patches generate entirely new revisions, is surprising to say the least.

This is unexpected. Please file this as a separate bug with a repro case if you've experienced it.

This is unexpected. Please file this as a separate bug with a repro case if you've experienced it.

Will do. I suspect this is probably more to do with not having tags in the commit message, which also causes other failures we're currently looking into.

am not 100% sure why you'd want to resubmit in the 'environment side-effects' case.

Specifically, the workflow I imagine is:

  • You run arc diff.
  • Unit tests fail because of some error in the harness itself.
  • You explain "I'm pretty sure this test failure isn't my fault, I'm going to go talk to Joe and see if he can help me fix this. Does the rest of this look OK?" when prompted.
  • You go talk to Joe, and he commits a fix to a separate library (libunittests) which fixes the test harness.
  • Back on your machine, you update libunittests to pick up Joe's fix and run arc diff again on the exact same changes.
  • This time, unit tests pass.
  • You write "Update with clean test run, failure wasn't related to my change (see rXyyy for discussion)."

We do this as a minor extension to the typical 'land' workflow. That is we have a wrapper that causes 'arc land' to be equal to 'arc diff -m "automated bump" && arc land'. We do this so that the latest version in differential maps exactly to the one that got landed. This also always causes a comment to be created immediately before land. We could possibly work around this locally by comparing the diff in differential (with getdiff or the modern equivalent) but it would be amazing if we could just tell phabricator "we're attempting to update but don't generate a new transaction if its exactly the same).

eadler added a project: Restricted Project.Oct 29 2016, 7:45 AM
eadler moved this task from Restricted Project Column to Restricted Project Column on the Restricted Project board.Nov 21 2016, 7:25 PM
epriestley claimed this task.

This is intended and has legitimate use cases.

The "compare" step can likely be done relatively easily by comparing tree hashes. We may get support for this, but I don't anticipate bringing support upstream if it's purely motivated by simplifying a complex add-on pipeline for one install.