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
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.
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:
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).
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.